Visualization Tool for Real-Time Dataflow Programming Language

ABSTRACT

A dataflow programming language can be used to express reactive dataflow programs that can be used in pattern-driven real-time data analysis. One or more tools are provided for the dataflow programming language for checking syntactic and semantic correctness, checking logical correctness, debugging, translation of source code into a secure, portable format (e.g., packaged code), translation of source code (or packaged code) into platform-specific code, batch-mode interpretation, interactive interpretation, simulation and visualization of the dataflow environment, remote execution, monitoring, or any combination of these. These tools embody a method of developing, debugging, and deploying a dataflow graph device.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is a continuation of U.S. patent applicationSer. No. 15/467,318, filed Mar. 23, 2017, issued as U.S. Pat. No.10,127,022 on Nov. 13, 2018, which claims the benefit of U.S. patentapplications 62/312,106, 62/312,187, 62/312,223, and 62/312,255, filedMar. 23, 2016. These applications are incorporated by reference alongwith all other references cited in this application.

BACKGROUND OF THE INVENTION

The invention relates to the field of computing, and more specifically adevelopment environment with tools for a dataflow program programminglanguage, especially for use in edge computing to handle the largeamounts of data generated by industrial machines.

Traditional enterprise software application hosting has relied ondatacenter or “cloud” infrastructure to exploit economies of scale andsystem efficiencies. However, these datacenters can be arbitrarilydistant from the points of physical operations (e.g., factories,warehouses, retail stores, and others), where the enterprise conductsmost of its business operations. The industrial Internet of things(IIoT) refers to a collection of devices or use-cases that relies oninstrumentation of the physical operations with sensors that trackevents with very high frequency.

Industrial machines in many sectors com under this Internet of things(IoT) including manufacturing, oil and gas, mining, transportation,power and water, renewable energy, health care, retail, smart buildings,smart cities, and connected vehicles. Despite the success of cloudcomputing, there are number of shortcomings: It is not practical to sendall of that data to cloud storage because connectivity may not always bethere, bandwidth is not enough, variation in latencies is too high, orit is cost prohibitive even if bandwidth exists. Even if connectivity,bandwidth, and cost are not issues, there is no real-time decisionmaking and predictive maintenance that can result in significant damageto the machines.

Therefore, improved development environment with tools for a dataflowprogram programming language are needed, especially for use in edgecomputing to handle the large amounts of data generated by industrialmachines.

BRIEF SUMMARY OF THE INVENTION

A dataflow programming language can be used to express reactive dataflowprograms that can be used in pattern-driven real-time data analysis. Oneor more tools are provided for the dataflow programming language forchecking syntactic and semantic correctness, checking logicalcorrectness, debugging, translation of source code into a secure,portable format (e.g., packaged code), translation of source code (orpackaged code) into platform-specific code, batch-mode interpretation,interactive interpretation, simulation and visualization of the dataflowenvironment, remote execution, monitoring, or any combination of these.These tools embody a method of developing, debugging, and deploying adataflow graph device.

In a specific implementation, tools for a dataflow program programminglanguage are used in an edge computing system. A method enablesintelligence at the edge. Features include: triggering by sensor data ina software layer hosted on either a gateway device or an embeddedsystem. Software layer is connected to a local-area network. Arepository of services, applications, and data processing engines ismade accessible by the software layer. Matching the sensor data withsemantic descriptions of occurrence of specific conditions through anexpression language made available by the software layer. Automaticdiscovery of pattern events by continuously executing expressions.Intelligently composing services and applications across the gatewaydevice and embedded systems across the network managed by the softwarelayer for chaining applications and analytics expressions. Optimizingthe layout of the applications and analytics based on resourceavailability. Monitoring the health of the software layer. Storing ofraw sensor data or results of expressions in a local time-seriesdatabase or cloud storage. Services and components can be containerizedto ensure smooth running in any gateway environment.

Edge intelligence is enabled at the source of the Internet of things(IoT) data. A system provides enriched access (stream or batch modes, orboth) to IoT device sensor data for real-time edge analytics andapplications. The system includes a highly efficient and expressivecomputer language for executing analytical functions and expressions,through a high performance analytics engine that operates in low memoryfootprint machines. The system allows publishing of aggregate data tocloud to further machine learning. The system includes a softwaredevelopment kit for developing edge apps. A cloud-based managementconsole allows managing of edge deployments, configuration,applications, and analytics expressions.

A specific implementation of an edge infrastructure and platform is byFogHorn Systems, Inc. (FogHorn). The FogHorn Web site,www.foghorn-systems.com, publications (including white papers, userguides, tutorials, videos, and others), and other publications aboutFogHorn technology and products are incorporated by reference.

FogHorn provides a platform to enable edge intelligence for industrialand commercial internet of things (IoT) data. The amount of datagenerated by tens of billions of industrial and commercial IoT deviceswill be massive enough to overwhelm the entire Internet. The FogHornplatform processes, analyzes, and responds to IoT data right where itoriginates—at the edge of the network. FogHorn's “intelligent edge”software platform enables unprecedented levels of automation,operational efficiency, cost savings, and much more.

The Industrial Internet of Things (IIoT) consists of interconnectedindustrial and commercial devices such as sensors, machinery, andcomputers. The goal of IIoT is to enable greater device control, datamanagement, machine automation, and operational efficiency across adistributed enterprise. Companies can apply fog computing at the edge tocapture greenfield IIoT opportunities using real-time analytics andautomated responses while also leveraging cloud computing forsystem-wide management and optimization. FogHorn edge computing platformis also designed to run in existing programmable logic controllers(PLCs) (e.g., Brownfield opportunities) if adding additional computingresources is not viable. Brownfield refers to an implementation of newsystems to resolve information technology (IT) problem areas whileaccounting for established systems. New software architecture takes intoaccount existing and running software.

Edge intelligence platform is a software-based solution based on fogcomputing concepts which extends data processing and analytics closer tothe edge where the IIoT devices reside. Maintaining close proximity tothe edge devices rather than sending all data to a distant centralizedcloud, minimizes latency allowing for maximum performance, fasterresponse times, and more effective maintenance and operationalstrategies. It also significantly reduces overall bandwidth requirementsand the cost of managing widely distributed networks.

Focusing on IIoT operations at the edge reduces overall bandwidthrequirements and enables immediate automated responses to time-sensitiveconditions. The industrial world is adding billions of new IIoT devicesand collectively these devices generate many petabytes of data each day.Sending all of this data to the cloud is not only very cost prohibitivebut it also creates a greater security risk. Operating at the edgeensures much faster response times, reduced risks, and lower overallcosts.

U.S. patent applications 62/210,981, filed Aug. 27, 2015, and Ser. No.15/250,720, filed Aug. 29, 2016, are incorporated by reference anddescribe an edge computing environment and platform. U.S. patentapplication Ser. No. 15/467,306, filed Mar. 23, 2017, is incorporated byreference and describes efficient state machines for real-time dataflowprogramming. U.S. patent application Ser. No. 15/467,313, filed Mar. 23,2017, is incorporated by reference and describes a composition ofpattern-driven reactions in real-time dataflow programming.

In an implementation, a development environment for a dataflowprogramming language allows specifying of at least one matcher statemachine that can perform pattern matching in a received an input streamand generate output data. The development environment includes toolsfor: identifying potential data streams; identifying a set of reactivefunctions and parameters corresponding to patterns of data in thestreams; identifying a set of handling functions and parameters fortransforming data matching declared patterns; or identifying a set oftimed events against which patterns of data flow are compared, or anycombination of these.

In another implementation, a system for dataflow programming developmentplatform includes a graphical user interface that is displayed on ascreen of a computer. There is a declarations screen where the user canspecify declarations data types. Blocks representing the declarationsdata types are displayed on the screen so that the user can drag anddrop the blocks into a desired position on the screen. There is areactions screen where the user can interconnect the blocks of thedeclarations data types into a graphical representation of a dataflowprogram. There is a compute block screen where the user can view andspecify an operation performed by a compute block. There is a code viewscreen where the user can view and edit a computer code representationautomatically generated by the development platform to implement thedataflow program. The user can request the development platforminterface to compile a dataflow program package representation of thedataflow program the user had specified.

In another implementation, a method of developing a dataflow programincludes: Using a graphical user interface to specify a graphicalrepresentation of a dataflow program. The user can select and moveproducer types, transducer types, and extractor types, represented usingblocks, into various positions on a computer screen. The user caninterconnect via interconnection links the blocks. The user can specifythe details of each of the blocks. A development platform automaticallygenerates computer source code that corresponds to the dataflow programthe user specified graphically. The user can view and edit the computersource code automatically generated in a textual or editor interface.The user to can direct the platform to generating computer package codefor the dataflow program that will be executable on a target hardwareplatform.

Other objects, features, and advantages of the present invention willbecome apparent upon consideration of the following detailed descriptionand the accompanying drawings, in which like reference designationsrepresent like features throughout the figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a block diagram of a client-server system and network.

FIG. 2 shows a more detailed diagram of a client or server.

FIG. 3 shows a system block diagram of a computer system.

FIG. 4 a block diagram of an edge computing platform, which is betweensensor streams and the cloud.

FIG. 5 shows a more detailed block diagram of an edge computing platformincluding edge analytics.

FIG. 6 shows an operational flow between edge infrastructure and cloudinfrastructure.

FIG. 7 shows an enhanced nondeterministic finite automaton (NFA)converted to a deterministic finite automaton (DFA) and state-reducedmachine.

FIG. 8 shows a transition from state A to B upon receipt of the tokenalpha.

FIG. 9 shows a transition from state A to B through a extra statetransition, state X.

FIG. 10 shows an example of an abstract syntax tree formed by thesyntactic analysis.

FIG. 11 shows a subgraph for alternation.

FIG. 12 shows a subgraph for conjunction.

FIG. 13 shows a closure with structures.

FIG. 14 shows a screen of verifying and testing logical correctness.

FIG. 15 shows a screen of a command debugger.

FIG. 16 shows a screen of a load directive.

FIG. 17 shows a screen of a status and manifest directive.

FIG. 18 shows a screen of a valve currently not open.

FIG. 19 shows a screen of a deadline directive.

FIG. 20 shows a screen of a valve to be open.

FIG. 21 shows a screen of a go directive.

FIGS. 22A-22B show a state and shape of data flow.

FIG. 23 shows a block diagram of pattern-driven flow-reactive conceptsfor a visualization studio development environment for dataflowprogramming.

FIG. 24 shows a screen of a declarations page of the developmentenvironment.

FIG. 25 shows a screen of a visualization studio's reactions page.

FIG. 26 shows another screen a declarations page where a user can dragand drop blocks into position on the screen to construct a dataflowprogram.

FIG. 27 shows a screen of specifying of a dataflow program in areactions page.

FIG. 28 shows a screen of details or internals of a compute block, whichthe user can modify.

FIG. 29 shows a screen of details of a compute block with annotations.

FIG. 30 shows a screen of showing a code panel with computer source codethat has been automatically generated by the development platform.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 is a simplified block diagram of a distributed computer network100 incorporating an embodiment of the present invention. Computernetwork 100 includes a number of client systems 113, 116, and 119, and aserver system 122 coupled to a communication network 124 via a pluralityof communication links 128. Communication network 124 provides amechanism for allowing the various components of distributed network 100to communicate and exchange information with each other.

Communication network 124 may itself be comprised of many interconnectedcomputer systems and communication links. Communication links 128 may behardwire links, optical links, satellite or other wirelesscommunications links, wave propagation links, or any other mechanismsfor communication of information. Communication links 128 may be DSL,Cable, Ethernet or other hardwire links, passive or active opticallinks, 3G, 3.5G, 4G and other mobility, satellite or other wirelesscommunications links, wave propagation links, or any other mechanismsfor communication of information.

Various communication protocols may be used to facilitate communicationbetween the various systems shown in FIG. 1. These communicationprotocols may include VLAN, MPLS, TCP/IP, Tunneling, HTTP protocols,wireless application protocol (WAP), vendor-specific protocols,customized protocols, and others. While in one embodiment, communicationnetwork 124 is the Internet, in other embodiments, communication network124 may be any suitable communication network including a local areanetwork (LAN), a wide area network (WAN), a wireless network, anintranet, a private network, a public network, a switched network, andcombinations of these, and the like.

Distributed computer network 100 in FIG. 1 is merely illustrative of anembodiment incorporating the present invention and does not limit thescope of the invention as recited in the claims. One of ordinary skillin the art would recognize other variations, modifications, andalternatives. For example, more than one server system 122 may beconnected to communication network 124. As another example, a number ofclient systems 113, 116, and 119 may be coupled to communication network124 via an access provider (not shown) or via some other server system.

Client systems 113, 116, and 119 typically request information from aserver system which provides the information. For this reason, serversystems typically have more computing and storage capacity than clientsystems. However, a particular computer system may act as both as aclient or a server depending on whether the computer system isrequesting or providing information. Additionally, although aspects ofthe invention have been described using a client-server environment, itshould be apparent that the invention may also be embodied in astand-alone computer system.

Server 122 is responsible for receiving information requests from clientsystems 113, 116, and 119, performing processing required to satisfy therequests, and for forwarding the results corresponding to the requestsback to the requesting client system. The processing required to satisfythe request may be performed by server system 122 or may alternativelybe delegated to other servers connected to communication network 124.

Client systems 113, 116, and 119 enable users to access and queryinformation stored by server system 122. In a specific embodiment, theclient systems can run as a standalone application such as a desktopapplication or mobile smartphone or tablet application. In anotherembodiment, a “web browser” application executing on a client systemenables users to select, access, retrieve, or query information storedby server system 122. Examples of web browsers include the InternetExplorer browser program provided by Microsoft Corporation, Firefoxbrowser provided by Mozilla, Chrome browser provided by Google, Safaribrowser provided by Apple, and others.

In a client-server environment, some resources (e.g., files, music,video, or data) are stored at the client while others are stored ordelivered from elsewhere in the network, such as a server, andaccessible via the network (e.g., the Internet). Therefore, the user'sdata can be stored in the network or “cloud.” For example, the user canwork on documents on a client device that are stored remotely on thecloud (e.g., server). Data on the client device can be synchronized withthe cloud.

FIG. 2 shows an exemplary client or server system of the presentinvention. In an embodiment, a user interfaces with the system through acomputer workstation system, such as shown in FIG. 2. FIG. 2 shows acomputer system 201 that includes a monitor 203, screen 205, enclosure207 (may also be referred to as a system unit, cabinet, or case),keyboard or other human input device 209, and mouse or other pointingdevice 211. Mouse 211 may have one or more buttons such as mouse buttons213.

It should be understood that the present invention is not limited anycomputing device in a specific form factor (e.g., desktop computer formfactor), but can include all types of computing devices in various formfactors. A user can interface with any computing device, includingsmartphones, personal computers, laptops, electronic tablet devices,global positioning system (GPS) receivers, portable media players,personal digital assistants (PDAs), other network access devices, andother processing devices capable of receiving or transmitting data.

For example, in a specific implementation, the client device can be asmartphone or tablet device, such as the Apple iPhone (e.g., AppleiPhone 6), Apple iPad (e.g., Apple iPad or Apple iPad mini), Apple iPod(e.g., Apple iPod Touch), Samsung Galaxy product (e.g., Galaxy S seriesproduct or Galaxy Note series product), Google Nexus devices (e.g.,Google Nexus 6, Google Nexus 7, or Google Nexus 9), and Microsoftdevices (e.g., Microsoft Surface tablet). Typically, a smartphoneincludes a telephony portion (and associated radios) and a computerportion, which are accessible via a touch screen display.

There is nonvolatile memory to store data of the telephone portion(e.g., contacts and phone numbers) and the computer portion (e.g.,application programs including a browser, pictures, games, videos, andmusic). The smartphone typically includes a camera (e.g., front facingcamera or rear camera, or both) for taking pictures and video. Forexample, a smartphone or tablet can be used to take live video that canbe streamed to one or more other devices.

Enclosure 207 houses familiar computer components, some of which are notshown, such as a processor, memory, mass storage devices 217, and thelike. Mass storage devices 217 may include mass disk drives, floppydisks, magnetic disks, optical disks, magneto-optical disks, fixeddisks, hard disks, CD-ROMs, recordable CDs, DVDs, recordable DVDs (e.g.,DVD-R, DVD+R, DVD-RW, DVD+RW, HD-DVD, or Blu-ray Disc), flash and othernonvolatile solid-state storage (e.g., USB flash drive or solid statedrive (SSD)), battery-backed-up volatile memory, tape storage, reader,and other similar media, and combinations of these.

A computer-implemented or computer-executable version or computerprogram product of the invention may be embodied using, stored on, orassociated with computer-readable medium. A computer-readable medium mayinclude any medium that participates in providing instructions to one ormore processors for execution. Such a medium may take many formsincluding, but not limited to, nonvolatile, volatile, and transmissionmedia. Nonvolatile media includes, for example, flash memory, or opticalor magnetic disks. Volatile media includes static or dynamic memory,such as cache memory or RAM. Transmission media includes coaxial cables,copper wire, fiber optic lines, and wires arranged in a bus.Transmission media can also take the form of electromagnetic, radiofrequency, acoustic, or light waves, such as those generated duringradio wave and infrared data communications.

For example, a binary, machine-executable version, of the software ofthe present invention may be stored or reside in RAM or cache memory, oron mass storage device 217. The source code of the software of thepresent invention may also be stored or reside on mass storage device217 (e.g., hard disk, magnetic disk, tape, or CD-ROM). As a furtherexample, code of the invention may be transmitted via wires, radiowaves, or through a network such as the Internet.

FIG. 3 shows a system block diagram of computer system 201 used toexecute the software of the present invention. As in FIG. 2, computersystem 201 includes monitor 203, keyboard 209, and mass storage devices217. Computer system 501 further includes subsystems such as centralprocessor 302, system memory 304, input/output (I/O) controller 306,display adapter 308, serial or universal serial bus (USB) port 312,network interface 318, and speaker 320. The invention may also be usedwith computer systems with additional or fewer subsystems. For example,a computer system could include more than one processor 302 (i.e., amultiprocessor system) or a system may include a cache memory.

Arrows such as 322 represent the system bus architecture of computersystem 201. However, these arrows are illustrative of anyinterconnection scheme serving to link the subsystems. For example,speaker 320 could be connected to the other subsystems through a port orhave an internal direct connection to central processor 302. Theprocessor may include multiple processors or a multicore processor,which may permit parallel processing of information. Computer system 201shown in FIG. 2 is but an example of a computer system suitable for usewith the present invention. Other configurations of subsystems suitablefor use with the present invention will be readily apparent to one ofordinary skill in the art.

Computer software products may be written in any of various suitableprogramming languages, such as C, C++, C#, Pascal, Fortran, Perl, Matlab(from MathWorks, www.mathworks.com), SAS, SPSS, JavaScript, AJAX, Java,Python, Erlang, and Ruby on Rails. The computer software product may bean independent application with data input and data display modules.Alternatively, the computer software products may be classes that may beinstantiated as distributed objects. The computer software products mayalso be component software such as Java Beans (from Oracle Corporation)or Enterprise Java Beans (EJB from Oracle Corporation).

An operating system for the system may be one of the Microsoft Windows®family of systems (e.g., Windows 95, 98, Me, Windows NT, Windows 2000,Windows XP, Windows XP x64 Edition, Windows Vista, Windows 7, Windows 8,Windows 10, Windows CE, Windows Mobile, Windows RT), Symbian OS, Tizen,Linux, HP-UX, UNIX, Sun OS, Solaris, Mac OS X, Apple iOS, Android, AlphaOS, AIX, IRIX32, or IRIX64. Other operating systems may be used.Microsoft Windows is a trademark of Microsoft Corporation.

Furthermore, the computer may be connected to a network and mayinterface to other computers using this network. The network may be anintranet, internet, or the Internet, among others. The network may be awired network (e.g., using copper), telephone network, packet network,an optical network (e.g., using optical fiber), or a wireless network,or any combination of these. For example, data and other information maybe passed between the computer and components (or steps) of a system ofthe invention using a wireless network using a protocol such as Wi-Fi(IEEE standards 802.11, 802.11a, 802.11b, 802.11e, 802.11g, 802.11i,802.11n, 802.11ac, and 802.11ad, just to name a few examples), nearfield communication (NFC), radio-frequency identification (RFID), mobileor cellular wireless (e.g., 2G, 3G, 4G, 3GPP LTE, WiMAX, LTE, LTEAdvanced, Flash-OFDM, HIPERMAN, iBurst, EDGE Evolution, UMTS, UMTS-TDD,1xRDD, and EV-DO). For example, signals from a computer may betransferred, at least in part, wirelessly to components or othercomputers.

In an embodiment, with a web browser executing on a computer workstationsystem, a user accesses a system on the World Wide Web (WWW) through anetwork such as the Internet. The web browser is used to download webpages or other content in various formats including HTML, XML, text,PDF, and postscript, and may be used to upload information to otherparts of the system. The web browser may use uniform resourceidentifiers (URLs) to identify resources on the web and hypertexttransfer protocol (HTTP) in transferring files on the web.

In other implementations, the user accesses the system through either orboth of native and nonnative applications. Native applications arelocally installed on the particular computing system and are specific tothe operating system or one or more hardware devices of that computingsystem, or a combination of these. These applications (which aresometimes also referred to as “apps”) can be updated (e.g.,periodically) via a direct internet upgrade patching mechanism orthrough an applications store (e.g., Apple iTunes and App store, GooglePlay store, Windows Phone store, and Blackberry App World store).

The system can run in platform-independent, nonnative applications. Forexample, client can access the system through a web application from oneor more servers using a network connection with the server or serversand load the web application in a web browser. For example, a webapplication can be downloaded from an application server over theInternet by a web browser. Nonnative applications can also be obtainedfrom other sources, such as a disk.

FIG. 4 shows a block diagram of an edge computing platform 406 typicallyrunning on an edge gateway or equivalent that is between sensors 409 andcloud 412. The edge computing platform enables deriving edgeintelligence that is important for managing and optimizing industrialmachines and other industrial Internet of things. Components of the edgegateway include the following: ingestion 421, enrichment 425, complexevent processing (CEP) engine 429, applications 432, analytics throughan expression language 435, and transport 438. The cloud can includeedge provisioning and orchestration 443 and cloud and edge analytics andapps portability 446.

As discussed above, a specific implementation of an edge computingplatform is from FogHorn. FogHorn is a leader in the rapidly emergingdomain of “edge intelligence.” By hosting high performance processing,analytics, and heterogeneous applications closer to control systems andphysical sensors, FogHorn's breakthrough solution enables edgeintelligence for closed loop device optimization. This brings big dataand real-time processing onsite for industrial customers inmanufacturing, oil and gas, power and water, transportation, mining,renewable energy, smart city, and more. FogHorn technology is embracedby the world's leading industrial Internet innovators and major playersin cloud computing, high performance edge gateways, and IoT systemsintegration.

Foghorn provides: Enriched IoT device and sensor data access for edgeapps in both stream and batch modes. Highly efficient and expressive DSLfor executing analytical functions. Powerful miniaturized analyticsengine that can run on low footprint machines. Publishing function forsending aggregated data to cloud for further machine learning. SDK(polyglot) for developing edge apps. Management console for managingedge deployment of configurations, apps, and analytics expressions.

FogHorn provides an efficient and highly scalable edge analyticsplatform that enables real-time, on-site stream processing of sensordata from industrial machines. The FogHorn software stack is acombination of services that run on the edge and cloud.

An “edge” solutions may support ingesting of sensor data into a localstorage repository with the option to publish the unprocessed data to acloud environment for offline analysis. However many industrialenvironments and devices lack Internet connectivity making this dataunusable. But even with Internet connectivity, the sheer amount of datagenerated could easily exceed available bandwidth or be too costprohibitive to send to the cloud. In addition, by the time data isuploaded to the cloud, processed in the data center, and the resultstransferred back to the edge, it may be too late to take any action.

The FogHorn solution addresses this problem by providing a highlyminiaturized complex event processing (CEP) engine, also known as ananalytics engine, and a powerful and expressive domain specific language(DSL) to express rules on the multitude of the incoming sensor streamsof data. Output from these expressions can then be used immediately toprevent costly machine failures or downtime as well as improve theefficiency and safety of industrial operations and processes in realtime.

The FogHorn platform includes: Ability to run in low footprintenvironments as well as high throughput or gateway environments. Highlyscalable and performant CEP engine that can act on incoming streamingsensor data. Heterogeneous app development and deployment on the edgewith enriched data access. Application mobility across the cloud andedge. Advanced machine learning (ML) and model transfer between cloudand edge. Out of the box, FogHorn supports the major industrial dataingestion protocols (e.g. OPC-UA, Modbus, MQTT, DDS, and others) as wellas other data transfer protocols. In addition, users can easily plug-incustom protocol adaptors into FogHorn's data ingestion layer.

FogHorn edge services operate at the edge of the network where the IIoTdevices reside. The edge software stack is responsible for ingesting thedata from sensors and industrial devices onto a high speed data bus andthen executing user-defined analytics expressions on the streaming datato gain insights and optimize the devices. These analytical expressionsare executed by FogHorn's highly scalable and small footprint complexevent processing (CEP) engine.

FogHorn edge services also include a local time-series database fortime-based sensor data queries and a polyglot SDK for developingapplications that can consume the data both in stream and batch modes.Optionally, this data can also be published to a cloud storagedestination of the customer's choice.

The FogHorn platform also includes services that run in the cloud oron-premises environment to remotely configure and manage the edges.FogHorn's cloud services include a management UI for developing anddeploying analytics expressions, deploying applications to the edgeusing an application known as Docker (www.docker.com), and for managingthe integration of services with the customer's identity accessmanagement and persistence solutions. The platform will also be able totranslate machine learning models developed in the cloud into sensorexpressions that can be executed at the edge.

As examples, an application applies real-time data monitoring andanalysis, predictive maintenance scheduling, and automated flowredirection to prevent costly damage to pumps due to cavitation events.Another example is wind energy management system using FogHorn edgeintelligence software to maximize power generation, extend equipmentlife, and apply historical analysis for accurate energy forecasting.

FIG. 5 shows a more detailed block diagram of an edge computingplatform. This platform has three logical layers or sections, dataingestion 512, data processing 515, and data publication 518. The dataingestion components include agents 520 that are connected to sensors ordevices 523 that generate data. The agents collect or ingest data fromthe sensors via one or more protocols from the respective protocolservers. The agents can be clients or brokers for protocols such as,among others, MQTT, OPC UA, Modbus, and DDS. The data provided or outputby the sensors is typically a binary data stream. The transmission ordelivery of this data from the sensors to the agents can be by push orpull methods.

Push describes a style of communication where the request for a giventransaction is initiated by the sender (e.g., sensor). Pull (or get)describes a style of communication where the request for thetransmission of information is initiated by receiver (e.g., agent).Another communication technique is polling, which the receiver or agentperiodically inquires or checks the sensor has data to send.

MQTT (previously MQ Telemetry Transport) is an ISO standardpublish-subscribe-based “lightweight” messaging protocol for use on topof the TCP/IP protocol. Alternative protocols include the AdvancedMessage Queuing Protocol, the IETF Constrained Application Protocol,XMPP, and Web Application Messaging Protocol (WAMP).

OPC Unified Architecture (OPC UA) is an industrial M2M communicationprotocol for interoperability developed by the OPC Foundation. It is thesuccessor to Open Platform Communications (OPC).

Modbus is a serial communications protocol originally published byModicon (now Schneider Electric) in 1979 for use with its programmablelogic controllers (PLCs). Simple and robust, it has since become for allintents and purposes a standard communication protocol. It is now acommonly available means of connecting industrial electronic devices.

Data processing 515 includes a data bus 532, which is connected to theagents 520 of the data ingestion layer. The data bus is the centralbackbone for both data and control messages between all connectedcomponents. Components subscribe to the data and control messagesflowing through the data bus. The analytics engine 535 is one suchimportant component. The analytics engine performs analysis of thesensor data based on an analytic expressions developed in expressionlanguage 538. Other components that connect to the data bus includeconfiguration service 541, metrics service 544, and edge manager 547.The data bus also includes a “decoder service” that enriches theincoming data from the sensors by decoding the raw binary data intoconsumable data formats (such as JSON) and also decorating withadditional necessary and useful metadata. Further, enrichment caninclude, but is not limited to, data decoding, metadata decoration, datanormalization, and the like.

JSON (sometimes referred to as JavaScript Object Notation) is anopen-standard format that uses human-readable text to transmit dataobjects consisting of attribute-value pairs. JSON is a common dataformat used for asynchronous browser or server communication (AJAJ) orboth. An alternative to JSON is XML, which is used by AJAX.

The edge manager connects to cloud 412, and in particular to a cloudmanager 552. The cloud manager is connected to a proxy for customeridentity and access management (IAM) 555 and user interface console 558,which are also in the cloud. There are also apps 561 accessible via thecloud. Identity and access management is the security and businessdiscipline that enables the right individuals to access the rightresources at the right times and for the right reasons.

Within data processing 515, a software development kit (SDK) 564component also connects to the data bus, which allows the creation ofapplications 567 that work that can be deployed on the edge gateway. Thesoftware development kit also connects to a local time-series databaseto fetch the data. The applications can be containerized, such as byusing a container technology such as Docker.

Docker containers wrap up a piece of software in a complete file systemthat contains everything it needs to run: code, runtime, system tools,and system libraries—anything that can be installed on a server. Thisensures the software will always run the same, regardless of theenvironment it is running in.

Data publication 518 includes a data publisher 570 that is connected toa storage location 573 in the cloud. Also, applications 567 of thesoftware development kit 564 can access data in a time-series database576. A time-series database (TSDB) is a software system that isoptimized for handling time series data, arrays of numbers indexed bytime (e.g., a date-time or a date-time range). The time-series databaseis typically a rolling or circular buffer or queue, where as newinformation is added to the database, the oldest information is beingremoved. A data publisher 570 also connects to the data bus andsubscribes to data that needs to be stored either in the localtime-series database or in the cloud storage.

FIG. 6 shows an operational flow between edge 602 and cloudinfrastructures. Some specific edge infrastructures were describedabove. Data is gathered from sensors 606. These sensors can be forindustrial, retail, health care, or medical devices, or power orcommunication applications, or any combination of these.

The edge infrastructure includes a software platform 609, which has dataprocessing 612, local time-series database 615, cloud sink 618,analytics complex event processing engine (CEP) 621, analytics real-timestreaming domain-specific language (DSL) 624 (e.g., the Vel language byFoghorn), and real-time aggregation and access 627. The platform caninclude virtual sensors 630, which are described below in more detail.The virtual sensors provide enriched real-time data access.

The platform is accessible via one or more apps 633, such as apps orapplications 1, 2, and 3, which can be developed using a softwaredevelopment kit or SDK. The apps can be heterogeneous (e.g., developedin multiple different languages) and leverage complex event processingengine 621, as well as perform machine learning. The apps can bedistributed using an app store 637, which may be provided by the edgeplatform developer or the customer of the edge platform (which may bereferred to as a partner). Through the app store, users can download andshare apps with others. The apps can perform analytics and applications639 including machine learning, remote monitoring, predictivemaintenance, or operational intelligence, or any combination of these.

For the apps, there is dynamic app mobility between edge and cloud. Forexample, applications developed using the FogHorn software developmentkit can either be deployed on the edge or in the cloud, therebyachieving app mobility between edge and cloud. The apps can be used aspart of the edge or as part of the cloud. In an implementation, thisfeature is made possible due to the apps being containerized, so theycan operate independent of the platform from which they are executed.The same can be said of the analytics expressions as well.

There are data apps that allow for integrated administration andmanagement 640, including monitoring or storing of data in the cloud orat a private data center 644.

A physical sensor is an electronic transducer, which measures somecharacteristics of its environment as analog or digital measurements.Analog measurements are typically converted to digital quantities usinganalog to digital converters. Sensor data are either measured on needbased (polled) or available as a stream at a uniform rate. Typicalsensor specifications are range, accuracy, resolution, drift, stability,and other attributes. Most measurement systems and applications utilizeor communicate the sensor data directly for processing, transportation,or storage.

The system has a “programmable software-defined sensor,” also called avirtual sensor, which is a software based sensor created using ananalytics expression language. In an implementation, the analyticsexpression language is FogHorn's analytics expression language. Thisexpression language is known as Vel. The Vel language is implementedefficiently to support real-time streaming analytics in a constrainedlow footprint environment with low latencies of execution. For example,a latency of the system can be about 10 milliseconds or less.

In an implementation, the programmable software-defined sensor iscreated with a declarative application program interface (API) called a“sensor expression language” or SXL. A specific implementation of an SXLlanguage is Vel from FogHorn. An Vel-sensor is a Vel-sensor createdthrough this construct, and provides derived measurements fromprocessing data generated by multiple sources including physical andVel-sensors. In this application, Vel and SXL are used interchangeably.

A Vel sensor can be derived from any one of or a combination of thesethree sources:

1. A single sensor data.

1.1. A virtual or Vel sensor derived from a single physical sensor couldtransform the incoming sensor data using dynamic calibration, signalprocessing, math expression, data compaction or data analytics, of anycombination.

2. Multiple physical sensor data.

2.1. A virtual or Vel sensor or derived as a transformation (using themethods described above) from multiple heterogeneous physical sensors.

3. A combination of physical sensor data and virtual sensor data madeavailable to the implementation of the Vel-sensor apparatus.

Vel sensors are domain-specific and are created with a specificapplication in mind. A specific implementation of Vel programminginterface enables applications to define data analytics throughtransformations (e.g., math expressions) and aggregations. Vel includesa set of mathematical operators, typically based on a programminglanguage. Vel sensors operate at runtime on data by executing Velconstructs or programs.

Creation of Vel Sensors. Vel sensors are designed as software apparatus'to make data available in real-time. This requires the execution ofapplications developed with the Vel in real-time on embedded computehardware to produce the Vel-sensor data at a rate required by theapplication. The system includes a highly efficient execution engine toaccomplish this.

Benefits of Vel sensors include:

1. Programmability. Vel makes Vel sensors programmable to synthesizedata to match specific application requirements around data quality,frequency and information. Vel-sensors can be widely distributed asover-the-air software upgrades to plug into data sourced from physicalsensors and other (e.g., preexisting) Vel sensors. Thus applicationdevelopers can create a digital infrastructure conducive to theefficient execution of business logic independent of the layout of thephysical infrastructure.

2. Maintainability or Transparency. Vel-sensors create a digital layerof abstraction between applications and physical sensors, whichinsulates developers from changes in the physical infrastructure due toupgrades and services to the physical sensors.

3. Efficiency: Vel-sensors create efficiencies in information managementby transforming raw data from physical sensors into a preciserepresentation of information contained in them. This efficiencytranslates into efficient utilization of IT resources like compute,networking, and storage downstream in the applications.

4. Real-time data: Vel-sensors provide real-time sensor data that iscomputed from real-world or physical sensor data streams. This makes thedata available for applications with minimum time delays.

Implementation. The system has architected a scalable, real-timeimplementation of Vel-sensors based on a Vel interface. Vel includesoperators supported by Java language and is well integrated withphysical sensors and their protocols.

The system brings a novel methodology for precisely expressing theoperations on physical sensors' data to be executed. This declarativeexpression separates the definition of the digital abstraction from theimplementation on the physical sensors.

Given a set of streams of data of varying types and a set of functionsmeant to react to and handle specific patterns of data in those streams,this invention is a technique to describe and translate those functionssuch that they can be invoked appropriately and efficiently as dataarrives in the streams.

The need to solve this sort of problem arises commonly in all forms ofdataflow programming. It is applicable to very large-scalearchitectures, such as the flow of data within and between enterprisedata centers, as well as to very small-scale architectures, such as theflow of events in an embedded device.

This invention is applicable to all domains of dataflow programming;however, it is most suitable in situations where the speed at which amatch can be detected and a handler function applied is of utmostimportance, and where there are limited storage and computing resourcesto devote to the execution.

Example

From a given stream of integers, we wish to match one or more non-zerovalues, followed by one or more zeros. When this pattern has beenmatched, we wish to compute the sum of the non-zero values and write theresult to another stream.

We could write the pattern-matching portion of this problem in a regularexpression notation, and then separately write the computation of thesum as an expression of arithmetic. As it happens, the Vel programminglanguage, designed for use in dataflow applications in edge computing,allows us to write the whole transform in a unified notation, thus:

stream(“output”) = ( a:{!= 0} .. {>0}, :0 .. {>0} −> sum(a) ) fromstream(“input”)

The technique would translate the above function parameterization into astate machine. It would then implement the match as a deterministicfinite automaton based on that state machine, and feed the resultingmatches to the summing expression. This flow is depicted in FIG. 7. Thisis a state 0 705, state 1 710, “from list a” block 715, and “pushsum(a)” block 720.

This problem can be solved by generating a matching function for eachhandler function. The matching function accepts as input a window ofdata from the streams and returns true for a match and false for anonmatch. As data flows through the windows, the matching functions mustbe applied repeatedly until a match is found. Once a match is found, thehandler function is applied.

This solution arises because the handler functions are specified in amanner similar to that used for database queries. An SQL-likeWHERE-clause provides a Boolean expression describing the conditions formatch and the matching function is a direct compilation of thisexpression.

The separate matching functions must be evaluated individually as newdata flows into the stream buffers. Matches are determined for eachfunction independently.

Using a state machine to perform the match is more efficient thanrepeatedly applying multiple, arbitrary Boolean expressions.

The present invention derives a state machine from a pattern descriptionlanguage that declares the parameters of a function. The derived statemachine more efficiently detects matches in a data stream thanconventional Boolean expression matching functions.

The derived state machine may also implement a set of handler functionsfor matches detected in the data stream. Multiple matching andcorresponding handler functions may be combined and reduced to a singlestate machine that efficiently recognizes matches for any handlerfunction.

The derived state machine may also be augmented to include free(epsilon) transitions through additional nodes without altering thesequence recognized by the state machine.

Transitioning through such an additional node may trigger variousactions on the data. For example, it may trigger collection of the datain the shift buffer of the deterministic finite automaton (DFA) or stackmachine into a holding area. These data may later form the basis forarguments to function application.

This application uses the term DFA, but these automatons or units may bereferred to stack machines. Strictly speaking, deterministic finiteautomaton implies finite performance in space. However, an automaton inthis patent is not necessarily finite, but can be nonfinite, yet stillsimple. Therefore, the DFAs as described in this patent may benonfinite.

Transitioning through such an additional node may also trigger theinvocation of a handler function, using the data captured in prior nodesas function application arguments.

Translation from a script combining aspects of regular expressions andvalue expressions gives rise to an augmented state machine or DFA whichcan efficiently match patterns and compute values.

The resulting combined matching or computing algorithm is more efficientthan separate organization of pattern matching and value computing.

A method for constructing the DFA or state machine from the lexicalsource, beginning with a nondeterministic finite automaton (NFA) andthen reducing it to a minimal DFA. The purpose of the DFA is torecognize a pattern within series of input data. For the purposes ofthis discussion, we will call the data flowing through the state machinetokens and a particular pattern recognized by the DFA as a language ofthe tokens.

Consider the portion of the NFA in FIG. 8. This portion also happens tobe a DFA, but this is not important for the purpose of this example. Ittransitions from state A 805 to state B 810 upon receipt of the tokenalpha.

We may augment this NFA by adding an additional node with an epsilontransition 920, as shown in FIG. 9. An epsilon edge may be followed atany time—for free, as it were—regardless of the state of input.

The presence of one or more epsilon edges make the state machinenondeterministic; however, epsilon edges may be removed by an algorithm,with the NFA reduced by this means to an equivalent DFA which can beimplemented efficiently by a table-driven method. We can thereforeintroduce these extra epsilon transitions while still retaining astrategy for efficient implementation.

The state machine in FIG. 9 will transition from state A 905 to state X915 upon receipt of token alpha 925, and can then proceed at will fromstate X to state B 910 at will. The impetus of alpha still results in atransition from state A to state B, just as it did in the simplermachine in FIG. 8, and no additional inputs are required to achieve thistransition. It can therefore be seen that the NFA in FIG. 9 translatesthe same language that in FIG. 8. It simply takes an extra statetransition, through state X, in order to do so.

The extra state is useful in that we may associate with it theperformance of side-effects. So long as these side-effects alter neitherthe definition of the state machine nor the data flowing through thestate machine, the additional node will have no effect on therecognition of language, but the side-effects can do additional work.

In a data flow reaction implementation, the additional work couldinclude any number of useful actions on or using the data. In oneexemplary implementation, the work can include:

1. Examining the data flowing through the node and emitting a copy of itto an outside collector;

2. Applying a transform to data as it flows through the node andcollecting the transformed data and in a temporary buffer; OR

3. Flushing collected data from a temporary buffer into an additionaltransform and pushing the result to another DFA or stack machine.

As an example, let us consider the source fragment:

-   (a:{!=0} . . . {>0}, :0 . . . {>0}->sum(a))

The fragment describes a pattern consisting of two terms: (1) A firstterm, called a, which matches one or more recurrences of nonzero values.(2) A second term, not given a name, which matches one or morerecurrences of zeros.

Let us suppose we wish to use this as the basis for a reaction. We willread values from a source called in, and when we recognize thefragment's pattern among the input, we will react by evaluating thefragment's right-hand side and pushing the result to a destinationcalled out.

For example, if in consisted of the values [101, 202, 303, 0, 0], wewould match the pattern by binding the first three values to a and thelast two values to the anonymous second term. We would then evaluate theright-hand side by applying the sum function to the list of values boundto a, [101, 202, 303], returning 606. We would then push 606 to out.

The translation of a functional pattern such as in this example inaccordance with this invention may be implemented via acomputer-executed translation program. The program would have to performtwo different forms of translation: translating the function-orientedportion “sum(a)” into a block of executable statements that wouldperform the computation, and translating the pattern-oriented portion“a: {!=0} . . . {>0}, :0 . . . {>0}” into a DFA or stack machine whichwould recognize the pattern, capture the arguments, and invoke thefunction. Let us call the former task function translation and thesecond task pattern translation.

Function translation is well understood by computer programmers whospecialize in the writing of compilers and interpreters. Patterntranslation, the fitting together of function translation and patterntranslation, and the subsequent automation of pattern recognition andfunction dispatch, are the subjects of this invention.

Function translation consists of accepting a source text, breaking thetext into tokens, and then, guided by a grammar, arranging the tokenssuch that they form the leaves of an abstract syntax tree (AST) whichdescribes the syntactic content of the source text. The abstract syntaxtree is then traversed by a series of algorithms which ultimatelyproduce the blocks of instructions required to evaluate the functionsdescribed by the source.

Pattern translation begins with the abstract syntax tree formed by thesyntactic analysis described above. The abstract syntax tree willcontain one or more nodes which form the roots of pattern declarations.For example, our pattern above might consist of a single root node withtwo children, each child describing one term of the pattern, as depictedin the lower-left portion of FIG. 10. In FIG. 10, there is a reactionroot node 1005, pattern root node 1010, sum(a) node 1015, a node 1020,and <no name> node 10.

Recognize that a pattern term node, specifying as it does an example tomatch and a recurrence with which to match it, carries the sameinformation as does a term in a regular expression. In addition, thesequence of child nodes, taken together and in order, specifies the sameinformation as a linear conjunction of regular expression terms. Alinear conjunction of regular expression or regular expression terms canbe translated terms into an NFA. We have discovered the same algorithmcan be used in the present invention, with pattern terms standing in forregular expression terms.

Once the basic NFA is so formed, we may inject into it our extra,side-effect-inducing states in positions where actions is required bypattern terms, and after the accepting state, to invoke reaction'sfunction.

To continue our example, term a requires that we collect a list of thevalues which match it so we may eventually pass them as an argument tothe reaction's function. We thus apply the transformation depicted inFIG. 9 to the NFA state resulting from term a and use the new state todo the work of collecting matching terms. We then apply thetransformation again, this time to the NFA's accepting state, and usethe collected values to call the reaction's function, push the result tothe reaction's consumers, and clear the collection buffer. After thisenhanced NFA is converted to a DFA and state-reduced, we are left withthe machine depicted in FIG. 7.

The steps are used to convert an NFA to a DFA, to state-reduce a DFA,and to render a DFA as a state-action table, as is the algorithm forusing a state-action table to drive a state-machine engine.

The NFA produced by a technique this invention can be transformed andrendered into a table. However, the resulting table includes an extracolumn consisting of the side-effect lambda to be executed when passingthrough each state. The automation engine that uses such astate-action-lambda table will, unlike other techniques, execute theadditional lambda each time it undergoes a transition.

A method for describing and translating reactive functions for use dataflow computing environments, includes: (i) identifying a reactivefunction; (ii) identifying the pattern of parameters providing inputs tothe function; (iii) identifying the expression to be evaluated based onthe arguments passed to the function; (iv) translating the pattern ofparameters into a state machine capable of recognizing the sequences ofinput which match the pattern; (v) augmenting the state machine withadditional states which do the work of collecting and transforming inputdata to prepare it for use as arguments to the function; and (vi)reducing the state machine to a state-action-effect table capable ofautomation by simple software or hardware.

Given a set of functions and a sequence of values as arguments, thisinvention is a method to dispatch execution to the function which thearguments match, or to determine that the arguments match none of thefunctions. This method is novel in that, by combining value expressions,type expressions, and regular expressions, it can match withoutambiguity any sequence of values representable in the type system.

The need to solve this type of problem arises in the development oftranslators, interpreters, and compilers and is closely related to thenotion of polymorphic dispatch. If one considers the elements forming anarbitrary prefix of the sequence to constitute single object (a tuple),then the task of dispatching to the correct function can be thought ofas equivalent to the polymorphic dispatch of method of the tuple'sclass.

This invention is applicable to any situation in which a this sort ofpolymorphic dispatch is required. This includes all manner ofevent-driven or reactive programs which must respond to a stream of dataoriginating from outside of the program. The invention will beparticularly useful in applications relating to the real-time processingof multiple streams of data, such as often occurs in edge or fogcomputing or networking environments.

Regular expressions are commonly used to detect strings which conform toa particular pattern. There are a number of regular expressionlanguages, most closely related, and many tools which implementefficient matching engines based on them. These are generally limited tomatching sequences of characters.

There are other pattern-based notations, which operate on domains otherthan strings. One example is XPATH, which describes patterns in XMLdocuments. These notations are often less complete and less powerfulthan regular expressions and are tailored for a specific domain.

Some programming languages implement runtime polymorphic dispatch bymeans of a type-based pattern matching system. Multiple overloads of afunction are defined, each taking a different pattern of types andvalues, and dispatch is resolved at runtime by matching the types andvalues of the arguments against the patterns of the function parameters.Haskell is one such programming language.

Language-specification languages describe context-free grammars as aseries production rules. These rules constitute the syntax of thelanguage. A compiler-compiler translates these rules into a table-drivendeterministic finite state machine which can recognize instances of thelanguage. Bison is an example of such a language-specification languageand its associated compiler-compiler.

Grammar-driven pattern-matching systems such as regular expressions havethe benefit of efficient execution due to being representable as simplemachines such as deterministic finite automata (DFAs) or state machines,but they lack the broad modeling capabilities of a full type system.Type-driven pattern-matching systems such as that used in Haskell havemuch richer modeling capabilities, but often sacrifice what isrepresentable in favor of a reasonably efficient implementation, yetstill are not as efficient as the high-speed matching systems based onDFAs.

This invention deals with a type-based matching system which can matchagainst all states representable in among its types and yet may still beimplemented efficiently as a state machine. A generalized pattern oftypes and states is translated into table-driven state machine whichwill efficiently recognize instances of the pattern.

Defining function parameters based on these patterns allows a functionto match exactly any arbitrary pattern of data and, in matching, bindits arguments from among the matching data elements. The state machinedescribing the matching pattern for a union of functions is formed bymerging the state machines of the member functions, then reducing theresult to a minimal number of states. Disambiguation between overloads,or detection of an overall nonmatch, occurs as early as possible in asequence, speeding the resolution of the function application. A matchmay also be delayed until as late as possible in a sequence, producingthe “greedy” version of the function which will accept as much input aspossible.

A method combines value expressions, type expressions, and regularexpressions, such that it can match without ambiguity any sequence ofvalues representable in the type system. This method resolves a functionapplication and dispatches to the correct overload with a minimal numberof decisions. This method allows an overloaded function application toperform the same work as context-free grammar, recognizing a specificlanguage by recursively recognizing grammatical subcomponents andapplying transformation functions thereto.

This method is applicable in connection with a type system including aplurality of different types, for example: (1) A set of foundationalmonomorphic types, such as integers, real numbers, and strings. (2) Aset of polymorphic types and their constructors, in particular apolymorphic set type with certain properties we shall shortly discuss.(3) A sum type. (4) A product type in the form of a record. (5) Aproduct type in the form of a pattern, which is a generalization of atuple to including repetition of its fields. (6) A lambda type, whichmaps a pattern type to any type. (7) And, a poly-lambda type, consistingof a list of lambdas.

A set is a polymorphic type consisting of one or more ranges ofelements. The set type is parameterized on the type of element itcontains, such that a set of integers is a distinct type from a set ofstrings, for example. A set type is further characterized by limits onits contents. In particular, a set type may be constrained to be finiteor infinite or to be closed or open on its left- or right-hand sides, orany combination of these. Consider the following examples of sets ofintegers:

TABLE A Notation Length Closedness Meaning [1] 1 closed on the left Aset consisting and right of the single integer 1. [1, 2, 3] 3 closed onthe left A set consisting and right of three integers: 1, 2, and 3.[5000 1001   closed on the left The integers from . . . and right 5000to 6000, 6000] inclusive. [10 . . .] infinite closed on the left, Allthe integers open on the right equal to or greater than 10. [. . . 10]infinite open on the left, All the integers closed on the right lessthan or equal to 10.  [>5] infinite closed on the left, All the integersopen on the right greater than 5. The same as [6 . . .]. [>=5] infiniteclosed on the left, All the integers open on the right greater than orequal to 5. The same as [5 . . .].  [<5] infinite open on the left, Allthe integers closed on the right less than 5. The same as [. . . 4].[<=5] infinite open on the left, All the integers closed on the rightless than or equal to 5. The same as [. . . 5]. [! = 5] infinite open onthe left All the integers and right except 5. [>=1] and 3 closed on theleft A set consisting [<=3] and right of three integers: 1, 2, and 3.The same as [1, 2, 3] or [1 . . . 3]. [<=−10] or infinite open on theleft All the integers [>=10] and right with an absolute magnitudegreater than or equal to 10. not [1 . . . 3] infinite open on the leftAll the integers and right except 1, 2, and 3.

There is no distinction between [>=1] and [>0] because the elements areof integer type and integers are distinctly enumerable. If the elementswere of a nonenumerable type, such as real numbers or strings, then theexplicit inclusion or inclusion of a specific endpoint becomesnecessary. For example, the set [>=“cat”] consists of the string “cat”and of all strings which sort lexicographically after “cat.”

We may use an instance of a set as a type. The instances of such a typemust be members of the set. For example, the set [>0], used as a type,would allow only positive integers as values. In fact, one may think ofall types in this way. For example, the monomorphic integer type couldbe considered a set type consisting of the set of all integers.

Our sum type is a simple union of other types. For example, the type intor string is the sum of its two constituent types. Any instance of anyof a sum type's constituent types is also an instance of the sum type.This allows us, for example, to describe the type list (int or string),which is a list of values, each of which is either an integer or astring. The union of unions flattens, so that the type expression (intor string) or (int or real) is equivalent to int or real or string. Theorder of the types in a union is not important, but for the sake of acanonicality, we present all union types here such that theirconstituents are in alphabetical order.

Our record type uses named fields and associates each field with a type.For example: {birthday: date; first name: string; last name: string}. Arecord type always has a finite number of fields and each field has aname unique within the type. The order of fields isn't important; {x:int; y: int} is the same as {y: int; x: int}; however, as we did forunions, we will present record types with their constituents inalphabetical order.

Note that the type of a record is itself a record. The value {x: 3; y:4} has the type {x: int; y: int}.

Our pattern type is similar to a tuple in that it is defined as asequence of types; however, while a tuple implicitly assumes each of itselements appears exactly once, a pattern permits each of its elements tohave a recurrence. The recurrence is given as a set of integers. Forexample, the pattern <a: int # [1 . . . 3]; b: string # [1 . . . 3]>matches one to three integers followed by one to three strings.

When used as the parameters of a lambda, the fields of a pattern giverise to arguments which are bound within the lambda's evaluation. Forexample, after we matched the pattern given in the previous paragraph,we would have two local identifiers, a and b, in scope. The value of Awould be a list of one to three integers and the value of b would be alist of one to three strings.

It is also valid for one or more fields in a pattern to have no name. Afield with no name is matched but no value for it is bound as anargument. For example, if we matched <a: int # [1 . . . 3]; string # [1. . . 3]>, we would match as before—one to three integers followed byone to three strings—and bind the integers as a list called a, but wewould not bind the strings.

A pattern may be of infinite length. For example the pattern <a: int #[1 . . . ]> will match one or more integers with no upper limit. This isvalid; however, if used to process an endless input stream, an infinitepattern must be paired with some other trigger, such as a time interval,which will indicate when to stop collecting values.

Generally a pattern will consume the data that it matches; however, itis possible to consume only a subset of that data, or none at all. Apattern may contain at mark, called the peek point, beyond which it willmatch data and bind arguments, but not consume from the input stream.For example, the pattern <a: int; b: int; peek; c: int> will match threeintegers and bind three local identifiers, but only consume two integersfrom the input.

It is valid to have a record with no fields or a pattern with no fields.These two cases are meaningfully indistinguishable from each other, asthey both denote the product type. Lexically, we designate this conceptwith the keyword void. The void is a unique value; it is also its owntype. Used in a union, the void gives rise to the notion of an optionaltype, such as int or void, meaning a value which, if present is an int,but might not be present at all.

For our purposes, type-matching is structural, not nominative. A typedoes not have a name, only a description. Two types with the samedescription are the same type. A type whose description is a subset ofthat of another type is a generalization of that type. For example,consider the types {x: int; y: int} and {x: int; y: int; z: int}. Thetype with two fields—x and y—is a subset of the type with threefields—x, y and z—and thus the former may be considered a generalizationof the latter. This is also true for patterns. A pattern which is aprefix of another is also its generalization.

Our lambda type maps an input pattern to an output type. For example<int # [1 . . . 3]>→int, which is the type of a function which takes oneto three integers and returns an integer. Our poly-lambda type is madeup of a list of lambda types. The order of the lambdas does matter here.When we are resolving a poly-lambda application, we will dispatch to thefirst of its constituent lambdas which matches.

Defined in this way, the pattern-matching required to dispatch apoly-lambda may be reduced to a deterministic finite automaton (DFA). Todemonstrate how, we will use a method of state machine construction as abasis for comparison and augment it as necessary. A description involvesfirst constructing a nondeterministic finite automaton (NFA) and thenreducing it to a DFA; however, in practice, this can generally be donein a single step.

As previously discussed, this application uses the term DFA, but theseautomatons or units may be referred to stack machines. Strictlyspeaking, deterministic finite automaton implies finite performance inspace. However, an automaton in this patent is not necessarily finite,but can be nonfinite, yet still simple. Therefore, the DFAs as describedin this patent may be nonfinite.

First, the constituents of the poly-lambda—the individual lambdapatterns—must be thought of as elements of an alternation. Intranslating a regular expression, the syntax a|b (a OR B) is analternation: match a 1105 or match b 1110. In our case, a AND b are eachlambda patterns. We construct a subgraph for alternation as per FIG. 11.

We represent the fields of an individual pattern first by conjunction.In translating a regular expression, the syntax ab 1210 is aconjunction: match a 1205, followed by b 1215. In our case, a AND b areeach fields of a pattern. We construct a subgraph for conjunction as perFIG. 12.

The repetition factor of a field is the same as a closure in a regularexpression, conventionally written as a+ or a* or a{n:m}. Again, we canrepresent these closures with structures like those in FIG. 13. In thiscase, some variation in the subgraph will be necessary based on thevalue of the repetition set. For example, the forward epsilon 1315 fromnode i 1305 to node j 1310 is only included if the set includes zero.These variations are largely obvious and continue along with the samebasic idea set forth here.

After the intermediate NFA is complete, we reduce it to a DFA, thenstate-reduce the DFA until a minimal DFA is reached. We then render theDFA as a state-action table, suitable for automation by the usual sortof software or hardware employed in automating state machines. Theaccepting states of this table mark the entry points to the poly-lambdaand the intermediate states provide the collection of data used to bindarguments.

When the DFA is so automated and provided a stream of inputs, it willmatch a prefix of inputs from the stream and dispatch to the correctoverload to handle them, yielding a computed result. If this process isallowed to repeat, the result is a sequence of yielded results, one permatch from the input stream. This provides efficient real-timeprocessing of the input data stream by polymorphic functions triggeredby corresponding patterns of arguments of various types detected in thedata stream.

A method for dispatching execution of polymorphic functions in responseto a data stream containing function arguments of multiple kinds,including a mixture of values and type identifiers, includes: (i)Identifying a polymorphic function to be executed, the polymorphicfunction having a plurality of overloads each associated with a patternof arguments of different kinds. (ii) Identifying for each overload anoutput expression to be evaluated over the set of argument values boundfrom the input stream by matching the argument pattern of the overload.(iii) Translating the argument pattern of each overload into a DFA whichwill efficiently recognize a match for the pattern in an input stream.(iv) Combining the DFAs of the individual overloads into a single DFAfor the polymorphic function as a whole, with the resulting combined DFAcapable of matching any pattern that would be matched by the individualDFAs and selecting the overload which should process the matching input.(v) Applying a data stream to the combined DFA, the DFA then examiningor consuming data from the stream, or both, as necessary to determine amatch or the absence of a match and, in the case of a match, binding theinput argument values appropriately and selecting the appropriate outputexpression to be evaluated. (vi) Dispatching evaluation of the outputexpression and returning the result.

Given a set of streams of data of distinct types being produced byreactive functions, this invention is a technique to represent thosestreams such that their outputs may be composed efficiently into asingle stream of unified type.

The need to solve this sort of problem arises commonly in all forms ofdataflow programming. It is applicable to very large-scalearchitectures, such as the flow of data within and between enterprisedata centers, as well as to very small-scale architectures, such as theflow of events in an embedded device.

This invention is applicable to all domains of dataflow programming;however, it is most suitable in situations where the speed at which amatch can be detected and a handler function applied is of utmostimportance, and where there are limited storage and computing resourcesto devote to the execution.

Example

Consider an inflow consisting of a set of n separate input streams,Ai:0<k<n. Each stream consists of a queue of elements of type Ti. Eachstream is being consumed and transformed by a reactive function, fi, ofthe type Ti→Ui, such there is an outflow n streams, Bi, each consistingof a queue of elements of type Ui. We desire to merge the all streams Biinto a single stream, C, using a merging function, m, of the typeΣTk→ΣUk.

Here is an example of such a merge occurring between three streams,written in the Vel language:

-   B0=f0 from A0-   B1=f1 from A1-   B2=f2 from A2-   C=B0 or B1 or B2

The stream C will consist of values from B0, B1, and B2, interleaved asthey are generated. Notice that there is no point to realizing thecontents of the B streams, as they are only used to compose the Cstream. They could just as easily be represented as anonymous, temporarysub expressions:

-   C=(f0 from A0) or (f1 from A1) or (f2 from A2)

This invention describes translation of each transformation function fiinto a deterministic finite automaton (DFA) and the merge function m asa union of these DFAs into a single, minimal DFA. The result is amaximally efficient means of merging the inflows Ai into the outflow Cwithout having to realize the contents of the intermediate flows Bi.

This technique may be applied repeatedly, conflating subsequent layersof intermediate flows into a single reactive function. This isconsistent with the notion of a merge being denoted by an infix oroperator in a declarative dataflow language, as is the case in Vel.

This problem is can be solved by brute force; that is, by realizing theintermediate flows and then consuming them, even if the merging functionis the only consumer of the intermediate flows.

It is often also the case that the merge function requires its inflowsand outflow to all be of the same type, or else of undifferentiated typein the case of typeless systems. This is due to a lack of union types(also called sum types) in their type systems. The presence of a truemerge in a dataflow system mandates the use of union types.

Some dataflow systems lack a true merge, instead implementingmulti-input-single-output reactive transforms. Although these are usefulconstructs in their own right, they are not as simple or general as atrue merging function and cannot be optimized as completely.

Representing a matching function as a DFA is more efficient thanexpressing it as an arbitrary expression of Boolean type. The DFAs ofmultiple matching functions, each with its own driving inflow, areunified to form a single, efficient DFA representing a merge functionwith a single outflow. The merging of the DFAs may be done such that theresult will match as early as possible or as late as possible, resultingin two different, potentially desirable behaviors. Composing multiplereactions into a single DFA results in a minimal machine; that is, analgorithm which performs all the matches using the minimal number ofdecisions. A minimal machine is most the suitable implementation ofmultiple reactions for small platforms. A minimal machine has analgorithmic advantage over multiple, separate evaluations of matchingexpressions and thus, all else being equal, will perform moreefficiently.

To merge the set of transformation DFAs into a single DFA, we mustconsider them as we would alternations in a regular expression. Intranslating a regular expression, the syntax a|b is an alternation:match a OR match b. In our case, a AND b are each DFAs fromtransformation functions. We construct a subgraph for their alternationas per FIG. 11.

After the intermediate nondeterministic finite automaton (NFA) iscomplete, we reduce it to a DFA, then state-reduce the DFA until aminimal DFA is reached. We then render the DFA as a state-action table,suitable for automation by the usual sort of software or hardwareemployed in automating state machines. The accepting states of thistable mark the points at which merged data elements are emitted to theoutput stream.

When the DFA is so automated and provided a set of input streams, itwill transform each input according to the original transformationfunction associated with that input, and yield all results interleavedtogether on a single output.

A method for merging multiple, independent streams of input data into asingle stream of output data, includes: (i) Identifying a plurality ofpotential input data streams. (ii) Identifying a plurality of transformfunctions, one per input stream, which are to be performed on the datain each input stream and the results of which are merged to be together.(iii) Identifying a merging function which receives input data elementsfrom multiple streams simultaneously and interleaves data elements intoa single output stream. (iv) Translating each transform function into aDFA which will efficiently perform the transform. (v) Merging thetransform DFAs into a single combined DFA which will efficiently performthe transforms and interleave the results into a single stream. (vi)Applying the data streams to the combined DFA, the DFA then performingthe work of transformation and merging. (vii) Dispatching the mergedoutput to a destination for use.

This invention includes a tool and associated methods for developingsoftware in the Vel programming language. Vel is a programming languageuseful for expressing dataflow programs. Correct dataflow programmingpresents many challenges. Some are challenges common to all forms ofcomputer programming while others are specific to the dataflow paradigm.

This tool addresses many areas of Vel programming, including: (1)Checking for syntactic and semantic correctness. (2) Checking forlogical correctness. (3) Debugging assistance. (4) Translation of sourcecode into a secure and portable form (that is, packaged code). (5)Translation of source code or packaged code into a native and optimalbinary form suitable for a variety computing platforms, particularlysmall platforms. (6) Describing packaged code and confirming itssignature. (7) Batch-mode interpretation of packaged code. (8)Interactive interpretation of Vel source. (9) Simulation of a dataflowenvironment in which to run packaged or native code. (10) Remoteexecution, monitoring, and control of binary code in a live dataflowenvironment.

These are the tasks which anyone developing software in the Vel languageneeds to accomplish. This invention provides sufficient support in allthese areas to allow a person proficient in Vel programming to producecorrect and useful software.

Checking for syntactic and semantic correctness is a task common to manyforms of automatic software translation. Tools for checking for logicalcorrectness are usually not incorporated into the translation toolitself. It is common for these sorts of tools to exist separately, oftenwith imperfect insight into the code they are testing.

Although debugging is a common task in software development, mostdebugging tools focus on imperative-style programming. Debugging offunctional and reactive programming is much less commonly addressed asit presents challenges very different from imperative debugging. Inparticular, it can be difficult to examine computations “in flight” inthese languages, as they values often do not have addresses at which thedebugger (and debugging programmer) may peek.

The ability to target multiple native platform architectures is notuncommon for compilers of system languages, such as C, but it is not apower to be commonly found among script-level languages. Scriptinglanguages tend not to be compiled, or to be partially compiled orjust-in-time compiled (jitted) for their hosts, but cross-compilation (acompiler running on one architecture but generating code for another) isuncommon. Specifically compiling a script-level language for executionon a small platform is extremely uncommon.

An interactive shell is a common feature of scripting languages. Python,for example, implements a shell. A shell which is connected to adataflow environment, real or simulated, is far less common.

Remote execution of compiled code is a feature of some operating systemsand is also available from several third-party tools, both open sourceand commercial. These tend not to target small platforms specifically,but some examples of remote execution tools for small platforms doexist. They are not specific to dataflow programming and are notincorporated into the tools used to develop the programs to be remotelyexecuted.

A single, integrated tool for developing Vel code is useful andconvenient for software developers working in the Vel language. The toolis principally a compiler, translating the Vel language, but it alsooffers several other sets of functions related to Vel programming.Having the tool perform logical correctness tests along with syntacticand semantic correctness tests helps the developer be more efficient andpromotes greater correctness of code. The logic tests have the benefitof the compiler's insight into the code, so diagnostic messages can bemore complete. The interactive shell enables the developer to test codeand get an immediate response. This is useful for development as well asdebugging. The shell also provides the programmer visibility into thedataflow environment.

Generating standalone binary executable code suitable for use on smallplatforms enables the Internet-of-Things use case, which often relies onperforming complex computation on a variety of small devices. Providinga simulated dataflow environment helps developers work out bugs in theircode and, in cooperation with tests for logical correctness,demonstrates that a package is working correctly. Remote execution of acompiled package, particularly when the remote platform is small, allowsa programmer to iterate quickly on his program, compiling and testingthe program on its target hardware in a single command, even if thetarget platform is not the one on which he is developing.

The process of translating a language from its lexical representation toan intermediate, symbolic representation (phase-1 compilation), and thentransforming this intermediate representation into a form which may beexecuted by computing hardware (phase-2 compilation).

The Vel phase-1 translation tool follows the general strategy common tocompilers, specifically: (1) Analyzing the input string to break it intoa sequence of tokens. (2) Analyzing the sequence of tokens to form asyntax tree. (3) Identifying symbolic declarations within the tree. (4)Identifying and resolving symbolic references within the tree. (5) Earlyoptimizations, such as common subexpression elimination and constantfolding. (6) Type-checking. (7) Additional phases of optimizations andsymbol maturation. (8) Finalization of symbols and emission ofintermediate representation.

One of the distinguishing features of the Vel phase-1 translator is itsuse of deterministic finite automata or DFAs to perform thepattern-matching required for function application and to triggerreactions. The phase-1 translation tool includes: (1) A syntax analyzertransforming the input language to a syntax tree. (2) A lexical bindingcomponent which permits the program under translation to makeself-reference, such that the language under analysis can be modified bythe analyzer, in the manner of a DSL or macro-analyzer. (3) A semanticanalysis algorithm translating the bound syntax tree into symbolsrepresentative of data flows, patterns, reactions, functionalexpressions, timers, and input/output parameterizations. (4) Anexpression translator which transforms expression trees into stackssuitable for more or less direct translation into microprocessor ALUinstructions. (5) A DFA generator for translating the patterns andexpressions of reactions into an intermediate collection of potentiallynonminimal DFAs. (6) And a DFA combining and reducing algorithm forproducing unified, minimal DFAs from the intermediate collection of DFA.

The output of the phase-1 translation tool includes: (1) The logicalidentities of each of the streams involved in the translation, such thateach may be a unique referent among the plurality of streams. (2) Adescription of the flow in the data in each stream, each being inward(toward the reactions; that is, a subscription to an external source),outward (away from the reactions; that is, a publication to an externaldestination), both inward and outward (a publication/subscription pair),or internal (used only as intermediate steps in other reactions andtherefore not surfaced as publications or subscriptions). (3) Adescription of the type of data flowing in each stream, each time beingdescribed in finite terms such that data being injected into orextracted from a stream may be statically checked for type correctness.(4) A set of tables describing the states and transitions of the DFAs.(5) A set of expression stacks describing the calculations which are tobe performed during reactions. (6) A table mapping stream inputs to DFAinputs. (7) A table mapping timed events to DFA inputs. (8) A tablemapping DFA outputs to action pairs, each pair consisting of a referenceto an expression stack and a stream output, indicating that the outputof the DFA is to be transformed by the given expression then pushed tothe given stream.

The Vel interpreter and dataflow simulator use the output of phase-1translation directly. The interpreter emulates a hardware platform inthe execution of the code and the dataflow simulator emulates astreaming data environment, providing inputs to and collecting outputsfrom Vel streams. Let us call these two tasks instruction interpretationand dataflow emulation.

Instruction interpretation is a category of task well understood bycomputer programmers who specialize in writing compilers andinterpreters. The task includes constructing an execution context inwhich the states of runtime variables may be stored, and then steppingthrough the instructions of the program one at a time, accessing datafrom the execution context and updating it as needed.

In the case of Vel, the execution context must also include a set ofqueues to hold streams of data in the process of transformation and atable-driven state machine engine to execute the transformationsdescribed by the DFAs. The queues arise due to declarations in the Velsource which describe flowing channels of data. Some of these areexternal inputs or outputs of the Vel program while others are purelyinternal channels describing intermediate states between input andoutput.

Dataflow emulation consists of providing access to external sources andsinks for data, such as files or sockets, and the programming necessaryto exchange data between these external systems and the Vel programunder interpretation. This will include injector functions, which readdata from external sources and push them to the queues representing theprogram's inputs, and extractor functions, which pop data from thequeues representing the programs outputs and write them to the externalsinks.

Where Vel interpretation according to the invention differs from thenorm is in the way the DFAs become involved. The state machine enginesread data from the queues and use them to advance the states of theirDFAs. The DFA tables include a column of side-effects which are executedwhen the DFAs move through their states. These side-effects invokeinstruction interpretation to perform computation, the results of whichare pushed to other queues and this trigger other DFAs.

In this way, a Vel program under interpretation according to theinvention is firstly represented by a set of state machines—which arefast and small—and only drop back to general instruction interpretationwhen necessary. This allows the program to execute with greaterefficiency than if it were all to be handled by instructioninterpretation alone.

The Vel phase-2 translation tool is, for the most part, not specific tothe Vel language but rather to the platform being targeted forexecution. The Vel-language-related components of the phase-2 translatorare: (1) Initial intake of the intermediate representation produced byphase-1. (2) Overall organization of the phase-2 code generation toproduce a reactive system. (3) Provision of a library of runtime supportcomponents, such as those that perform external encoding and decoding ofdata formats or the internal regulation of real-time clocks.

A tool for creating programs for real-time processing of data streams ina multi-source, multi-destination data flow environment, includes: (1)Identifying a plurality of potential data streams. (2) Identifying a setof reactive functions and parameters corresponding to patterns of datain the streams. (3) Identifying a set of handling functions andparameters for transforming data matching declared patterns. (4)Identifying a set of timed events against which patterns of data floware compared, such as intervals of time in which data are to becollected or discarded or specific points in time before or after whichdata are to be collected or discarded. (5) Creating a dataflow programdescribing the identified streams, reactions, functions, and timedevents. (6) Providing the program as input to a two-phase translationtool comprising a phase-1 translation tool incorporating a DFA generatorfor translating Vel program statements to corresponding DFAs and aphase-2 translation tool for generating platform-specific hardwareinstructions corresponding to the translated Vel statements forexecution on the platform. (7) Receiving the output of each phase of thetranslation tool.

The output of the phase-1 translation tool may be used by theinterpreter component, includes: (1) An instruction interpreter whichemulates a hardware platform in the execution of the code. (2) A dataflow simulator which emulates a streaming data environment, providinginputs to and collecting outputs from Vel streams.

The output of the phase-1 translation tool may be used as the input tothe phase-2 translation tool, includes: (1) A hardware instructiongenerator which translates instructions from the intermediaterepresentation to a form suitable for execution by the target hardwareplatform. (2) A program organization module, which directs thegeneration of the output into a form suitable for use in a reactiveprogram in a dataflow environment. (3) Libraries of runtime supportcomponents necessary for execution. The output of the phase-2translation tool is an executable program suitable for use on thetargeted hardware platform.

A single, integrated tool for developing Vel code is useful andconvenient for software developers working in the Vel language. The toolexecutes on a host platform, consisting of a standard computer andoperating system, such as an Intel x86 architecture microcomputerrunning the Linux operating system. The tool may interact with othertools and facilities of the platform, such as a web browser orintegrated development environment (IDE). If the platform has a networkinterface device, the tool may also access remotely hosted resources. Ifthe host permits access to the Internet, the tool may also accessInternet-based resources.

The tool is principally a compiler, translating the Vel language, but italso offers several other sets of functions related to Vel programming,including: (1) A driver for testing logical correctness, to verify,demonstrate, and document the correct operation of Vel programs. (2) Aninteractive shell for language interpretation, to facilitate rapiditeration in Vel program development and to help demonstrate theoperation of Vel programs. (3) An interactive program debugger, tofacilitate the investigation and correction of malfunctions in Velprograms.

Vel interaction shell and debugger. Even though the debugging is commonin software development activities and numerous tools exist these toolsonly let you debug in an imperative step-wise in style. The burden ofthe sense of logic flow and semantics still lies with the human usingthe tool. Interactive shells are common as well for various programminglanguages but what a technique of this invention provides is asignificant improvement by providing very unique semantic-leveldebugging capabilities. This helps a Vel programmer focus exclusively onthe business logic or semantic-based debugging, or both; significantlyexpediting the problem solving process.

Live debugging and inspecting or monitoring of running Vel programs: Thetool also improves upon the concept of being able to debug or monitorlive running Vel programs. Typically for monitoring or inspectingrunning processes or programs, or both, extra instrumentation orexternal tools are needed. In the context of an Industrial IoTenvironment this problem becomes excruciatingly worse with hundred ofthousands of sensor data points that needs to be inspected againstdesired outcome. This make the management and debugging to dataflowrelated problems almost intractable at scale. The tool solves theproblem by exposing default internal self-inspection data-flow regimewhich can be externally queried at any time to quickly fetch thesemantics of data flow and what is going on in the moment; in-flight. Insimple words: when a program does not behave as expected or does notproduce data as expected; one could just query the program to ask why itdid not work and it just tells you. For real-time streaming dataanalysis this is significant improvement since a lot of programdebugging needs to be done with data in-flight; in the moment.

Example

In this section we provide a simple concrete example of the tool inaction. We start with a concrete use-case and a Vel program for it. Thenwe step into using the tool to demonstrate the capabilities describedabove. Consider a sensor input stream for a valve. The valve that opensand closes as conditions change. When the valve is open sensor readingis: “true” and then the valve closed the sensor reading is “false.”

The input_stream is a record with two fields in it:

-   (Integer) timestamp-   (Boolean) is_open

The goal is to detect when exactly the valve opened and send a true toan output stream. So in terms of sensor readings we detected a falsefollowed by a true. An important pattern matching stream processingfeature involved here is: Valve close-to-open transition detection via asliding window pattern using TFR (1).

Sample JSON formatted real data coming in from input stream data:

-   Valve-   {“timestamp”:1473223600, “is_open”: false}-   {“timestamp”:1473224302, “is_open”: false}-   {“timestamp”:1473224402, “is_open”: true} . . . so on forever

Vel Program:

-   sensor_data is {is_open is bool, timestamp is int} #sensor data_type    definition-   #1. Input Stream Definition-   def stream valve_status is sensor_data-   #2. Valve Open Event Detection Windowing Pattern Declaration. We    create a window of size 2 that slides 1 at a time on incoming    streaming data-   open_event is (item1:sensor_data, peek, item2:sensor_data->-   item1.is_open==false and item2.is_open==true)-   #3. Pattern application directly on incoming stream to get desired    output result-   def stream valve_opened=true select event from (open_event from    valve_status)-   when event==true

Verifying and testing logical correctness. FIG. 14 shows a screen ofverifying and testing logical correctness. Although this is a smallconcrete example to demonstrate program correctness coupled with logicalverification (flow of meaning). One could extrapolate this to fairlycomplex data-flow problem. In which the ability of the tool to detectthe syntax incorrectness and also logic (semantic) incorrectness is veryuseful.

Interactive shell and live debugging: The Vel development tool providesan interactive debugger that runs in a terminal. This tool is usefulduring development of Vel scripts, to confirm that they are operating asexpected or to figure out what's wrong with them.

Entering and exiting the debugger: The same tool which compiles Vel alsoserves as its debugger. FIG. 15 shows a command debugger. The command is“debug.” This drops you into an interactive session in your terminal.You can tell when you are in the Vel debugger because you will see a“vel>” prompt. To exit the debugger, press ctrl+d or quit.

Loading: Before you can work with a package, you must load it. The LOADdirective reads a script from a file, translates it, and holds it as apackage in the debugger, ready to run.

FIG. 16 shows an example of a load directive. This loads the “test.vel”script and assigns it the logical name “valve_test.” We will use thename “valve_test” from now on when we want to refer to this package. Thepackage has not yet started, however. An unstarted package cannot reactto inputs and won't produce any outputs. You may load as many packagesas you like. When they are running, they will run in parallel andcommunicate with each other over topics, just as they would in a liveedge node.

FIG. 17 shows a status and manifest directive. You can see whichpackages are loaded with the STATUS directive and you can see thestreams of each package with the MANIFEST directive.

Starting Up. Use the STARTUP directive to start all your packagesrunning. You can also startup an individual package by specifying itsname, but it's often useful to start them all at once. If a package thathas startup actions will execute them as soon as it starts. Once it hasstarted, the package may react to incoming data and produce resultsaccording to its stream definitions. You may change the bindings of astarted package without stopping it or unloading it.

Data Injection. The INJECT directive allows you to inject data directlyinto a stream without binding it to an external source. This bypassesthe need to have additional infrastructure or tools setup to pump dataexperiment. For example: In this example we have been discussing we willfirst pump that the status of the valve is currently not open. So we aretelling the program artificially that the valve is currently not open.

FIG. 18 shows a valve currently not open. The value being injected isgiven in Vel script, not as a quoted string, and it is not subject toany form of transcoding. You are constructing a Vel value directly andstuffing it into the stream. After injection, the value behavesnormally. Reactions and other computations based on it will proceed justas though the value had been received from the broker. Direct injectionis convenient when you just want to try running some values through apackage. The package must be started before you can inject to it.

Deadlines. One of the key features of the tool is: Time in the debuggeris artificial. It only flows when you tell it to, allowing you to steppackages forward and see how they behave. The time at which the debuggerstarts is called “start” and the debugger's current time is called“now.” All other times are given relative to these. There are noabsolute times. Each package has a future time in mind when it wouldnext like to act. This is the deadline of the package. You can see thedeadline of each package with the DEADLINE directive:

FIG. 19 shows a deadline directive. A deadline of “never” means there isno deadline. In this case, the “valve_test” package has no deadlinemeaning the package is purely reactive (that is, it does not take actionbased on its own timers) and currently has no pending inputs, so itdoesn't care if it ever runs again. Remember, the use-case was todetermine if the valve_status is a false followed by a true. The “next”line at the end tells you the soonest deadline among all the packages.In this case, as there is only one loaded package, the next deadline isthe same as the deadline for “valve_test,” which is “never.” A packagewith a deadline of “now” is ready to run immediately. A package withpending inputs is always ready “now,” is it wants to process thoseinputs. If a package has running timers, it may have a deadline based onthem. Such a deadline might be something like “now+25 (ms).”

FIG. 20 shows a valve to be open. Now to exercise the logic of theprogram we will inject the valve_status to be true; the valve to beopen. Injecting a true here would indicate that the pattern that iswaiting for the data to match a false followed by a true windows would.The pattern match satisfies the condition for the reaction to happenswhich means if our assumed logic is correct we should see an output onthe valve_opened. This is the most accurate detection of a logical eventfrom raw sensor data.

FIG. 21 shows a GO directive. Making it go. The GO directive causes thedebugger to run forward to the soonest deadline. The debugger hasallowed the “valve_test” package to react to its pending input now byusing go. This didn't require any time to pass, as the input was alreadywaiting. The pattern was indeed matched and we now have an output forit.

-   valve_test.valve_opened see the value true our intended goal.

Automated Debugging. It is often convenient to run the debugger througha preset series of directives. To facilitate this, the debugger providesthe DO directive: vel> do “stored_directives.vdbg.”

This will read the directives stored in the file“stored_directives.vdbg” and execute them one at a time, in order. It'sthe same as if you had typed them into the debugger, but without all thetyping.

Replaying capture live data into the debugger. In debugging livescenario is it often convenient to capture “live” data from the existingdata source and replay it into the Vel debugger. That way you cancontrol execution like a video editor and semantic debug with datain-flight. The external injection of the notion of time helps inspectany part of the system.

Live inspect of already running Vel programs in production: This is thepart of the tool that helps to extract live state of a running Velprograms in production. Circling back to the point made earlier the toolsolves the problem but exposing default internal self-inspectiondata-flow regime which can be externally queried at any time to quicklyfetch the semantics of data flow and what is going on in the moment;in-flight.

Example Usage:

-   $ vel dump_graph <name_of_a_running_program>

This dumps both the state and shape of the data flow. The output of thiscan be then plotted continuously in the visualization studio (describedbelow) that details out the value of seeing the flow visually. FIGS.22A-22B shows state and shape of data flow. In FIG. 22A, a line 2205 islonger than can be viewed in the portion of the screen shown in thefigure. The remaining portion of line 2205 is shown as line 2207 in FIG.22B.

Other sets of functions related to Vel programming include: (4) Aplatform-independent, cryptographically secure program packager, toallow a Vel program to be translated into an obfuscated, executable,platform-independent form (a package) that contains the programdefinitions as well as information about the program's origination (suchas the program's version, the author's name and contact information, theintended license for use of the program, relevant legal notices, andother such meta-information), along with a cryptographic digest of thepackage and a digital signature to verify its contents, to facilitateand standardize the process of releasing (possibly multiple versions of)developed Vel programs for use by others while providing a reliablemeans of verifying the program's origin and internal integrity;

5. A cryptographically secure program package importing facility, tofacilitate and standardize the process of importing (possibly multipleversion of) Vel programs developed by others while providing a reliablemeans of verifying the program's origin and internal integrity.

6. A cryptographically secure program package inspection facility, toallow a developed package to be inspected reliably for its contents,including its authorship, version, and other meta-information, itsprogrammatic definitions, and its internal help and documentation, andto verify the package's cryptographic security, and to renderinformation about the package into forms (such as JSON and HTML) usefuland friendly to external automation and direct human consumption.

7. A package interpreter, to allow a packaged Vel program to be executedon the host platform without full compilation to the host's nativearchitecture, and which provides to the running program a variety ofsupporting abilities, such as the ability to subscribe to or publish tostreaming data channels according to certain standards and protocols,the ability to encode or decode data according to certain standards andprotocols, the ability to compress or decompress data according tocertain standards and protocols, and the ability to encrypt or decryptdata according to certain standards and protocols.

8. A cross-platform executable code generator, to translate Vel programsor packages, or both, into compact, efficient forms that can executenatively on a variety of platforms, including the host platform, and toinclude in the executables various components of reusable (library)executable code as may be necessary or convenient to fulfill the usefuloperation of the program, such as components to enabling subscripting toand publishing to streaming data channels according to certain standardsand protocols, components to enable the encoding and decoding of dataaccording to certain standards and protocols, to compress or decompressdata according to certain standards and protocols, to encrypt or decryptdata according to certain standards and protocols.

9. A remote deployment and maintenance facility, to allow developed Velprograms to be transmitted to and installed on remote hosts in a secureand verifiable manner, to allow programs thus installed to be upgradedwhen new versions become available, to allow programs thus installed tobe removed from the remote host when no longer needed, to allow programsthus installed to be started running on the remote host, to allow suchprograms running on a remote host to be monitored for correctness,performance, and normal course of operation, and to allow such programsrunning on a remote host to be stopped from running.

10. A dataflow simulation studio, to provide a realistic dataflowenvironment in which to develop, verify, and demonstrate Vel programs,including the ability to subscribe to and publish to streaming datachannels, to record the live contents of streams, to create simulatedstreams, to edit the contents of recorded or simulated streams, to playback recorded or simulated streams, to pause or stop the playback ofrecorded or simulated streams, and to rewind or repeat, or both, inwhole or in part the playback of recorded or simulated streams.

11. A program visualization studio, to allow a Vel program to bedisplayed or revised, or both, or authored in a graphical fashion,wherein Vel program components are represented graphically as nodes andthe data links between components are represented graphically as edges,thus assisting a user to gain a more intuitive and thoroughunderstanding of the action of the Vel program.

12. A dataflow visualization studio, to allow, in concert with theprogram visualization studio, dataflow environment studio, and anyrelevant and accessible live data streams, the animated, graphicaldisplay of streaming data flowing through a Vel program, thus allowingthe user to see how data enters, is transformed by, and leaves programcomponents, to see changes in the program's internal state as a resultof the flow of data, to monitor the program's correctness, performance,and normal course of operation, and to assist in the detection,diagnosis, and correction of any erroneous operation.

Program or dataflow visualization and simulation studio: The program ordataflow visualization and simulation tool is a Web-based that uses theVel tool in the backend for it various services already described abovein the patent.

FIG. 23 shows a block diagram of a visualization studio's pattern-drivenflow-reactive concepts. The visualization studio is a developmentenvironment for a dataflow programming language. In a specificimplementation, the development environment is for the Vel dataflowprogramming language and is known as “Visual Vel Maker.” The dataflowprogramming language has three overall components—inputs, reactions, andoutput—that are designed around Vel's pattern-driven flow-reactiveconcepts.

FIG. 24 shows a screen of visualization studio's declarations page. Thedataflow development environment has a declarations page 2405 where theuser can declares things that statically exist. There is reactionsbutton 2409 which a user can select to change to a reactions page whichis discussed below.

On the declaration page, some examples of declarations include streamdefinitions (e.g., representing sensors), patterns (e.g., declaringpattern or patterns to match, specifying TFR(1)), timers, user-definedfunctions, complex data types, and so forth. There is tool bar an iconand button for each of the definition types, stream 2422, constants2426, user-defined types 2430, timer 2434, user-defined functions 2438,and patterns 2442.

There is a compile button 2451, which the user can select and use tocompile a program into a portable package representation, which can beexecuted outside the development environment. There is an export button2453, which the user can use export a program into another format. Thereis a code panel button 2456, which the user can use to open a code panelview of a program. In the code panel, there is a textual view of theprogram. The code panel can have editing capabilities of a text editor,so that a user can edit the code. This may be helpful for an advanceduser who wants to code directly.

FIG. 25 shows a screen of visualization studio's reactions page 2504. Inthe reactions page, the user will have a run-time view of the analyticintent of the dataflow program. The user can add compute blocks (whichcan be referred to as transducers). The page can also show the inputs(which can be referred to as injectors) and outputs (which can bereferred to as extractors), such as input streams, local streams, andoutput streams.

FIG. 26 shows another screen of the visualization studio's declarationspage. This screen is representative of how a user can use drag-and-dropto move the declarations into different positions on the screen, inorder to construct a desired dataflow program. The screen shows blocksfor constants 2611, user-defined types 2613, streams 2616 and 2618(presented in two columns), a timer 2422, a user-defined function 2425,and patterns 2627.

FIG. 27 shows a screen of visualization studio's reactions page and howa user can specify a dataflow program. There are inputs (e.g.,injectors), compute blocks (e.g., transducers), and outputs (e.g.,extractors). The user specifies the dataflow program by specifying thedeclarations (blocks defined on the declarations page),interconnections, compute block (e.g., matcher program, such as TFR(1)specification), and outputs.

As an example, in a particular program depicted in the figure, somestreams 2708 (which can be software or hardware sensor devices) are usedas input. The user specifies an interconnection 2713 (e.g., blocks shownwith line connections) of the inputs to some compute blocks 2717.Outputs of the compute blocks are connected via interconnections 2723(which the user specifies) to some stream blocks 2728 (e.g, intermediatetransducers). The stream blocks are connected via interconnections 2734to stream outputs 2737 (e.g., extractors).

This example shows how some components or blocks in the system can beused for various purposes, such as a stream block being used as atransducer and an extractor. Further, the user can click on a block onthe screen and another window or screen will pop-up that will show theinternals of the block. For example, by clicking on a compute block, theinternals of the compute block will be shown on the screen.

FIG. 28 shows a screen of showing details or internals of a computeblock. This screen may be used to view, specify, or revise thespecifications or contents of a compute block. There is a data selectionsection 2802, condition section 2804, and data actions section 2085. Foreach data value of the involved inputs streams, the things as specifiedon this screen will happen in the compute block.

FIG. 29 shows the screen of the compute block with additionalannotations. From left-to-right, the compute block transforms data byinput, compute, condition, compute, and output. The model visuallyimplements the dataflow program's pattern matching, transformation,conditional evaluation, and so forth. The environment is intuitive forthe user.

In the example depicted, there are streams for an inlet pressure 2915and outlet pressure 2919. These streams provide inlet and outletpressure values. These values are connected to a diff block 2924, whichperforms a difference operation. Then, an output of the diff block is adifference between the inlet and outlet pressure values. This differenceoutput is connected to a local pressure stream output 2928. This computeblock can be used as a transducer to provide a virtual sensor streaminglocal pressure based on two sensor inputs.

FIG. 30 shows a screen showing a code panel. After the user specifiesthe details of the compute block graphically, the developmentenvironment can generate the computer code for the compute block. Theuser can open a code panel 3005 to see a textual view of the code forthe compute block program in a pop-up window that overlays the reactionsscreen.

In the code panel, the user can view the code, and as desired, the usercan edit the code. Advanced users may prefer to specify some portions ofthe compute block by coding instead of or in combination with thegraphical interface.

In an implementation, the development environment is Web based, wherethe software executes in a Web browser. In another implementation, thedevelopment environment is desktop software executes in an operatingsystem, without the need for a Web browser.

Having the tool perform logical correctness tests along with syntacticand semantic correctness tests helps the developer be more efficient andpromotes greater correctness of code. The logic tests have the benefitof the compiler's insight into the code, so diagnostic messages can bemore complete.

The interactive shell and debugging facilities enable the developer totest code and get an immediate response and to inspect code director toconfirm its correctness or diagnose its error. These are vitalactivities during program development.

The generation, inspection, interpretation, and sharing of packaged Velprograms (which may be referred to as packages) greatly assists inprogram development by facilitating a practice of code reuse. A package,once developed and tested, becomes a reliable building block for furtherdevelopment. The package also becomes the common form in which softwaredevelopers distribute their Vel-based products to users without needingto worry about each user's specific platforms. The user's confidence inand ability to exploit such packages increases because the user is freeto inspect the package and verify its integrity without help from theoriginal author.

Generating stand-alone binary executable code suitable for use on avariety of platforms, especially on platforms, enables theInternet-of-Things (IoT) use case, which often relies on performingcomplex computation on a variety of small devices. The reuse of existingpackages on new hardware by cross-compilation enables a heterogeneousand flexible IoT environment.

The remote deployment and monitoring facilities are also vital for theIoT use case. Once developed, a package can be deployed easily to afar-flung and heterogeneous fleet of remote hosts, yet still runoptimally on each host by virtue of having been cross-compiledespecially for it. The activity of a deployed across the fleet packagecan be monitored and controlled from a central point, simplifyingoperations.

Remote execution of a compiled package, particularly when the remoteplatform is too small to provide a convenient development environment,also allows a programmer to iterate quickly on his program, compilingand testing the program on its target hardware in a single command,while maintaining the convenience of developing on the platform of hisor her choice.

Providing a simulated dataflow environment helps developers work outbugs in their code and, in cooperation with tests for logicalcorrectness, demonstrates that a package is working correctly. Dataflowsimulation is also useful in educational settings, to assist in salesdemonstrations, and in other situations where live data is not availableor desirable.

Likewise, program and dataflow visualization greatly assist in theprocess of software development. The programmer can work intuitivelywith the program and dataflow environment, navigating more swiftlybetween components than is generally possible with text-baseddevelopment alone, and inspecting and modifying active programcomponents and the data being acted upon in situ.

One of the distinguishing features of the Vel phase-1 translator is itsuse of the TFR(1) algorithm to construct efficient state machines(“matchers”) to perform the pattern-matching required to triggerreactions and apply attribute computation functions. A specificpattern-matching technique is called timed forward right-most (1)pattern matching or TFR(1).

The phase-1 translation tool includes: (1) A syntax analyzertransforming the input language to a syntax tree. (2) A lexical bindingcomponent which permits the program under translation to makeself-reference, such that the language under analysis can be modified bythe analyzer, in the manner of a domain-specific language (DSL) analyzeror macro-analyzer. (3) A semantic analysis algorithm translating thebound syntax tree into symbols representative of data flows, patterns,reactions, functional expressions, timers, and input/outputparameterizations. (4) An expression translator which transformsexpression trees into stacks suitable for more or less directtranslation into microprocessor ALU instructions. (5) A matchergenerator for translating the patterns and expressions of reactions intoan intermediate collection of potentially suboptimal matchers. (6) And amatcher combining and optimizing algorithm for producing unified,minimal matchers from the intermediate collection of matchers.

The output of the phase-1 translation tool includes: (1) The logicalidentities of each of the streams involved in the translation, such thateach may be a unique referent among the plurality of streams. (2) Adescription of the flow in the data in each stream, each being inward(toward the reactions; that is, a subscription to an external source),outward (away from the reactions; that is, a publication to an externaldestination), both inward and outward (a publication/subscription pair),or internal (used only as intermediate steps in other reactions andtherefore not surfaced as publications or subscriptions). (3) Adescription of the type of data flowing in each stream, each time beingdescribed in finite terms such that data being injected into orextracted from a stream may be statically checked for type correctness.(4) A set of tables describing the states and transitions of thematchers. (5) A set of expression stacks describing the calculationswhich are to be performed during reactions. (6) A table mapping streaminputs to matcher inputs. (7) A table mapping timed events to matcherinputs. (8) A table mapping matcher outputs to action pairs, each pairconsisting of a reference to an expression stack and a stream output,indicating that the output of the matcher is to be transformed by thegiven expression then pushed to the given stream.

The Vel interpreter and dataflow simulator use the output of phase-1translation directly. The interpreter emulates a hardware platform inthe execution of the code and the dataflow simulator emulates astreaming data environment, providing inputs to and collecting outputsfrom Vel streams. Let us call these two tasks instruction interpretationand dataflow emulation.

Instruction interpretation is a category of task well understood bycomputer programmers who specialize in writing compilers andinterpreters. The task includes constructing an execution context inwhich the states of runtime variables may be stored, and then steppingthrough the instructions of the program one at a time, accessing datafrom the execution context and updating it as needed.

In the case of Vel, the execution context must also include a set ofqueues to hold streams of data in the process of transformation and atable-driven state machine engine to execute the transformationsdescribed by the matchers. The queues arise due to declarations in theVel source which describe flowing channels of data. Some of these areexternal inputs or outputs of the Vel program while others are purelyinternal channels describing intermediate states between input andoutput.

Dataflow emulation consists of providing access to external sources andsinks for data, such as files or sockets, and the programming necessaryto exchange data between these external systems and the Vel programunder interpretation. This will include injector functions, which readdata from external sources and push them to the queues representing theprogram's inputs, and extractor functions, which pop data from thequeues representing the programs outputs and write them to the externalsinks.

Where Vel interpretation according to the invention differs from thenorm is in the way the matchers become involved. The matcher drivingengine reads data from the queues and uses them to advance the states ofthe matchers. The matcher tables include a column of side-effects whichare executed when the matchers move through their states. Theseside-effects invoke instruction interpretation to perform computation,the results of which are pushed to other queues and this trigger othermatchers.

In this way, a Vel program under interpretation according to theinvention is firstly represented by a set of state machines—which arefast and small—and only drop back to general instruction interpretationwhen necessary. This allows the program to execute with greaterefficiency than if it were all to be handled by instructioninterpretation alone.

The Vel phase-2 translation tool is, for the most part, not specific tothe Vel language but rather to the platform being targeted forexecution. The Vel-language-related components of the phase-2 translatorare: (1) Initial intake of the intermediate representation produced byphase-1. (2) Overall organization of the phase-2 code generation toproduce a reactive system. (3) Provision of a library of runtime supportcomponents, such as those that perform external encoding and decoding ofdata formats or the internal regulation of real-time clocks.

A distinguishing feature of the Vel phase-2 translator is itsimplementation of the reactive system as a tristate flowgraph. A toolfor creating programs for real-time processing of data streams in amulti-source, multi-destination data flow environment, includes: (1)Identifying a plurality of potential data streams. (2) Identifying a setof reactive functions and parameters corresponding to patterns of datain the streams. (3) Identifying a set of handling functions andparameters for transforming data matching declared patterns. (4)Identifying a set of timed events against which patterns of data floware compared, such as intervals of time in which data are to becollected or discarded or specific points in time before or after whichdata are to be collected or discarded. (5) Creating a dataflow programdescribing the identified streams, reactions, functions, and timedevents. (6) Providing the program as input to a two-phase translationtool comprising a phase-1 translation tool incorporating a matchergenerator for translating Vel program statements to correspondingmatchers and a phase-2 translation tool for generating platform-specifichardware instructions corresponding to the translated Vel statements forexecution on the platform. (7) Receiving the output of each phase of thetranslation tool.

The output of the phase-1 translation tool may be used by theinterpreter component, includes: (1) An instruction interpreter whichemulates a hardware platform in the execution of the code. (2) A dataflow simulator which emulates a streaming data environment, providinginputs to and collecting outputs from Vel streams.

The output of the phase-1 translation tool may be used as the input tothe phase-2 translation tool, includes: (1) A hardware instructiongenerator which translates instructions from the intermediaterepresentation to a form suitable for execution by the target hardwareplatform. (2) A program organization module, which directs thegeneration of the output into a form suitable for use in a reactiveprogram in a dataflow environment. (3) Libraries of runtime supportcomponents necessary for execution. In an implementation, the output ofthe phase-2 translation tool is an executable program suitable for useon the targeted hardware platform.

In an implementation, a development environment for a dataflowprogramming language allows specifying of at least one matcher statemachine that can perform pattern matching in a received an input streamand generate output data. The development environment includes tools toperform at least one of the following: identifying potential datastreams; identifying a set of reactive functions and parameterscorresponding to patterns of data in the streams; identifying a set ofhandling functions and parameters for transforming data matchingdeclared patterns; and identifying a set of timed events against whichpatterns of data flow are compared, such as intervals of time in whichdata are to be collected or discarded or specific points in time beforeor after which data are to be collected or discarded. In animplementation, the dataflow programming language is Vel from FogHorn.

Further, the tools can perform at least one of the following: creating adataflow program from expressed intent which describes the identifiedstreams, reactions, functions, and timed events; providing the programas input to a two-phase translation tool comprising a first-phasetranslation tool incorporating a matcher generator for translatingprogram statements to corresponding matchers, data flow topologies,functions, and related symbolic components, and a second-phasetranslation tool for generating optimized platform-specific hardwareinstructions corresponding to the translated statements for execution onthe platform; and receiving the output of each phase of the translationtool.

The development environment has a graphical user interface or GUI thatallows a user to add one or more compute blocks, where each computeblock implements a state machine. The graphical user interface allowsthe user to select an input block to connect to one or more addedcompute blocks. The graphical user interface allows the user to selectan output from one or more added compute blocks to connect to an outputblock (e.g., extractor) or to other transducers (e.g., stream blocks orcompute blocks).

The development environment includes an interpreter component that usesthe output of the first-phase translation tool. There is an instructioninterpreter that emulates a hardware platform in the execution of thecode. There is a data flow simulator which emulates a streaming dataenvironment, providing inputs to and collecting outputs from statemachine streams. There is a program execution flow controller to examinecomputations and data in-flight and drive computations back and forth.

The development environment includes a live inspection component. Aninspection method instruments and attaches to a live running program onparticular hardware program, and provides insights into the shape of thedataflow graph. There is an inspection method, executing afterattachment, which extracts the state of the dataflow computation of arunning program and provides an extremely precise and direct insightinto computation along with data in consideration.

The development environment includes a visualization and data-flowsimulation graphical-based component. There is a graphical-basedinterface (or Web-based interface, or a combination) to allow a programto be authored or displayed or revised in a graphical fashion. Thisassists a user to gain a more intuitive mental-model for streaming dataanalysis and thorough understanding of the action of the program. Thereis a dataflow simulation to test-drive an authored graphical program byvisually simulating the actual flow of data via animations and links.There simulation component has external control by injecting a notion oftime allowing the fluidity to go back and forth in data-flow andcomputation.

The interpreter component uses the output of the first-phase translationtool. An instruction interpreter emulates a hardware platform in theexecution of the code. A data flow simulator emulates a streaming dataenvironment and providing inputs to and collects outputs from statemachine streams. A program execution flow controller examinescomputations and data in-flight and drives computations back and forth.

The first-phase translation tool includes a simulatedpublisher-subscriber multiplexer (typically called a message broker) tofacilitate the exchange of simulated messages from a plurality ofpublishers to a number of subscribers within a debugging environment.

The development environment includes a live inspection component. Thereis an inspection method that instruments and attaches to a live-runningprogram on a particular hardware program, and provides insights into theshape of the dataflow graph. There is an inspection method, executingafter attachment, which extracts the state of the dataflow computationof a running program. The inspection method also provides an extremelyprecise and direct insight into computation along with data inconsideration.

An output of the first-phase translation tool may be used as an input tothe second-phase translation tool. The translation tool can include: Ahardware instruction generator which translates instructions from theintermediate representation to a form suitable for execution by thetarget hardware platform. A program organization module, which directsthe generation of the output into a form suitable for use in a reactiveprogram in a dataflow environment. And libraries of runtime supportcomponents that allow execution on the target hardware platform. In animplementation, an output of the second-phase translation tool is anexecutable program suitable for use on the targeted hardware platform.

In an implementation, a system for dataflow programming developmentplatform includes a graphical user interface that is displayed on ascreen of a computer. Using a declarations screen of the graphical userinterface of the development platform, the user can specify declarationsdata types including streams, constants, functions, and patterns. Apattern definition is used to specify a pattern to identify in a stream.Blocks representing the declarations data types are displayed on thescreen so that the user can drag and drop the blocks into a desiredposition on the screen.

Using a reactions screen of the graphical user interface of thedevelopment platform, the user can interconnect the blocks of thedeclarations data types into a graphical representation of a dataflowprogram. In the reactions screen, the user can specify and alterinterconnects (visible as wires or lines) between the different blocks.

Using a compute block screen of the graphical user interface of thedevelopment platform, the user can view and specify an operationperformed by a compute block. The user can specify inputs to the computeblock and computations on the inputs, and an output of the computerblock. Using a code view screen of the graphical user interface of thedevelopment platform, the user can view and edit a computer coderepresentation of the operation graphically represented in the computeblock screen. The computer code is automatically generated by thedevelopment platform.

Using a compile command (e.g., graphical button) for the developmentplatform interface, the user can direct the development platforminterface to compile a dataflow program package representation of thedataflow program the user has specified using the development platforminterface. A stream type block can be used as a producer of data andalso as transducer, taking input data and outputting data.

Further components of the development platform include: An instructioninterpreter emulates a hardware platform in the execution of the code. Adataflow simulator interface emulates a streaming data environment,providing inputs to and collecting outputs from state machine streams. Aprogram execution flow controller examines computations and datain-flight and drive computations back and forth. A simulatedpublisher-subscriber multiplexer facilitates the exchange of simulatedmessages from a plurality of publishers to a plurality of subscriberswithin a debugging environment.

In an implementation, a method of developing a dataflow programincludes: Using a graphical user interface to specify a graphicalrepresentation of a dataflow program, the program comprising producertypes, transducer types, and extractor types. Through the graphical userinterface, the user can select and move the producer types, transducertypes, and extractor types, represented using blocks, into variouspositions on a computer screen. Using the graphical user interface,allowing the user to interconnect via interconnection links the blocksrepresenting the producer types, transducer types, and extractor types.Allowing the user to specify the details of each of the blocks throughthe graphical user interface, where for a transducer type block, theuser can specify an operation. Automatically generating computer sourcecode that corresponds to the dataflow program the user specified usingthe graphical user interface. Allowing the user to view and edit thecomputer source code automatically generated in a textual interface.Allowing the user to specify generating of a computer package of codeexecutable on a target hardware platform that is an implementation ofthe dataflow program specified by the user using the graphical userinterface.

The operation in a transducer block is a pattern matching operation. Theautomatically generating computer source code implements the operationusing a state machine reflecting a technique that processes data of aninput stream of a producer without backtracking. In anotherimplementation, the automatically generating computer source codeimplements the operation using a state machine reflecting a techniquethat processes stream data from an input of a producer only once, anddoes not retain data previously read in a buffer to read again later. Aproducer can be a virtual representation of a hardware sensor.

This description of the invention has been presented for the purposes ofillustration and description. It is not intended to be exhaustive or tolimit the invention to the precise form described, and manymodifications and variations are possible in light of the teachingabove. The embodiments were chosen and described in order to bestexplain the principles of the invention and its practical applications.This description will enable others skilled in the art to best utilizeand practice the invention in various embodiments and with variousmodifications as are suited to a particular use. The scope of theinvention is defined by the following claims.

The invention claimed is:
 1. A method comprising: providing adevelopment environment for a dataflow programming language allowingspecifying of at least one state machine that can perform patternmatching in a received input stream and generate output data, whereinthe development environment comprises a plurality of tools to perform atleast one of the following: identifying a plurality of potential datastreams; identifying a set of reactive functions and parameterscorresponding to patterns of data in the streams; identifying a set ofhandling functions and parameters for transforming data matchingdeclared patterns; identifying a set of timed events against whichpatterns of data flow are compared; creating a dataflow program fromexpressed intent which describes at least one of identified streams,reactions, functions, or timed events; providing the dataflow program asinput to a two-phase translation tool comprising a first-phasetranslation tool incorporating a matcher generator for translatingprogram statements to at least one of corresponding matchers, data flowtopologies, functions, or related symbolic components, and asecond-phase translation tool for generating optimized platform-specifichardware instructions corresponding to the translated statements forexecution on a hardware platform; and receiving the output of each phaseof the translation tool.
 2. The method of claim 1 wherein the graphicaluser interface allows the user to select an input block to connect toone or more added compute blocks.
 3. The method of claim 2 wherein thegraphical user interface allows the user to select an output from one ormore added compute blocks to connect to an output block.
 4. The methodof claim 1 wherein the timed events comprise at least one of an intervalof time in which data is to be collected or discarded or a specificpoint in time before or after which data is to be collected ordiscarded.
 5. The method of claim 1 wherein the development environmentcomprises a graphical user interface allowing a user to add one or morecompute blocks, and each compute block comprises a state machine.
 6. Themethod of claim 4 wherein the development environment comprises agraphical user interface allowing a user to add one or more computeblocks, and each compute block comprises a state machine.
 7. The methodof claim 1 wherein the development environment has a graphical userinterface allowing a user to add one or more compute blocks, whereineach compute block comprises a state machine.
 8. The method of claim 1wherein the development environment comprises an interpreter componentthat uses the output of the first-phase translation tool comprising: aninstruction interpreter which emulates the hardware platform in theexecution of platform-translated specific hardware instructions; a dataflow simulator which emulates a streaming data environment, providinginputs to and collecting outputs from state machine streams; and aprogram execution flow controller to examine computations and datain-flight and drive computations back and forth.
 9. The method of claim1 wherein the development environment comprises an inspection componentcomprising: an inspection method that instruments and attaches to a liverunning program on a particular hardware program, providing insightsinto the shape of a data graph; and an inspection method, executingafter attachment, then extracts the state of the dataflow computation ofa running program which provides an extremely precise and direct insightinto computation along with data in consideration.
 10. The method ofclaim 1 wherein the development environment comprises a visualizationand dataflow simulation graphical-based component comprising: agraphical-based interface to allow a program to be authored or displayedor revised in a graphical fashion, thereby assisting a user to gain amore intuitive mental-model for streaming data analysis and thoroughunderstanding of the action of the program; and a data flow simulationto test-drive an authored graphical program by visually simulating theactual flow of data via animations and links, with external control byinjecting a notion of time allowing the fluidity to go back and forth indata-flow computation.
 11. The method of claim 10 wherein thefirst-phase translation tool comprises a simulated publisher-subscribermultiplexer, commonly called a message broker, to facilitate theexchange of simulated messages from a plurality of publishers to aplurality of subscribers within a debugging environment.
 12. The methodof claim 10 wherein the development environment comprises an interpretercomponent that uses the output of the first-phase translation toolcomprising: an instruction interpreter which emulates the hardwareplatform in the execution of platform-translated specific hardwareinstructions; a data flow simulator which emulates a streaming dataenvironment, providing inputs to and collecting outputs from statemachine streams; and a program execution flow controller to examinecomputations and data in-flight and drive computations back and forth.13. The method of claim 12 wherein the first-phase translation toolcomprises a simulated publisher-subscriber multiplexer, commonly calleda message broker, to facilitate the exchange of simulated messages froma plurality of publishers to a plurality of subscribers within adebugging environment.
 14. The method of claim 12 wherein thedevelopment environment comprises an inspection component comprising: aninspection method that instruments and attaches to a live runningprogram on the particular hardware program, providing insights into theshape of a data graph; and an inspection method, executing afterattachment, then extracts the state of the dataflow computation of arunning program which provides an extremely precise and direct insightinto computation along with data in consideration.
 15. The method ofclaim 1 wherein the output of the first-phase translation tool may beused as an input to the second-phase translation tool, and thetranslation tool comprises: a hardware instruction generator whichtranslates instructions from the intermediate representation to a formsuitable for execution by the target hardware platform; a programorganization module, which directs the generation of the output into aform suitable for use in a reactive program in a dataflow environment;and libraries of runtime support components that allow execution on thetarget hardware platform.
 16. The method of claim 15 wherein an outputof the second-phase translation tool is an executable program suitablefor use on the targeted hardware platform.
 17. A method comprising:using a graphical user interface to specify a graphical representationof a dataflow program, the program comprising producer types, transducertypes, and extractor types, wherein through the graphical userinterface, the user can select and move the producer types, transducertypes, and extractor types, represented using blocks, into selectedpositions on a computer screen; using the graphical user interface,allowing the user to interconnect via interconnection links the blocksrepresenting the producer types, transducer types, and extractor types;allowing the user to specify details of each of the blocks through thegraphical user interface, wherein for a transducer type block, the usercan specify an operation, and the operation in a transducer block is apattern matching operation; and allowing the user to specify generatingof a computer package of code executable on a target hardware platformthat is an implementation of the dataflow program specified by the userusing the graphical user interface.
 18. The method of claim 17comprising: automatically generating computer source code thatcorresponds to the dataflow program the user specified using thegraphical user interface.
 19. The method of claim 18 comprising:allowing the user to edit the computer source code automaticallygenerated in a textual interface.
 20. The method of claim 18 wherein theautomatically generating computer source code implements the operationusing a state machine reflecting a technique that processes data of aninput stream of a producer without backtracking.
 21. The method of claim18 wherein the automatically generating computer source code implementsthe operation using a state machine reflecting a technique thatprocesses stream data from an input of a producer only once, and doesnot retain data previously read in a buffer to read again later.
 22. Amethod comprising: providing a development environment for a dataflowprogramming language allowing specifying of at least one state machinethat can perform pattern matching in a received input stream andgenerate output data, wherein the development environment comprises aplurality of tools to perform at least one of the following: identifyinga plurality of potential data streams; identifying a set of reactivefunctions and parameters corresponding to patterns of data in thestreams; identifying a set of handling functions and parameters fortransforming data matching declared patterns; identifying a set of timedevents against which patterns of data flow are compared; creating adataflow program from expressed intent which describes at least one ofidentified streams, reactions, functions, or timed events; providing avisualization graphical-based component comprising a graphical-basedinterface to allow a dataflow program to be displayed graphically,wherein the graphical-based interface allows the user to make revisionsto the program graphically; providing a dataflow simulationgraphical-based component comprising a graphical-based interfacecomprising a data flow simulation to test-drive an authored graphicalprogram by visually simulating the actual flow of data via animationsand links; and providing the dataflow program as input to a two-phasetranslation tool comprising a first-phase translation tool incorporatinga matcher generator for translating program statements to at least oneof corresponding matchers, data flow topologies, functions, or relatedsymbolic components, and a second-phase translation tool for generatingoptimized platform-specific hardware instructions corresponding to thetranslated statements for execution on a hardware platform; andreceiving the output of each phase of the translation tool.
 23. Themethod of claim 22 wherein the dataflow simulation graphical-basedcomponent comprises an external control by injecting a notion of timeallowing the fluidity to go back and forth in data-flow computation. 24.The method of claim 22 wherein the development environment comprises aninspection component comprising: an inspection method that instrumentsand attaches to a live running program on a particular hardware program,providing insights into the shape of a data graph; and an inspectionmethod, executing after attachment, then extracts the state of thedataflow computation of a running program which provides an extremelyprecise and direct insight into computation along with data inconsideration.
 25. The method of claim 22 wherein the developmentenvironment comprises an interpreter component that uses the output ofthe first-phase translation tool comprising: an instruction interpreterwhich emulates the hardware platform in the execution ofplatform-translated specific hardware instructions; a data flowsimulator which emulates a streaming data environment, providing inputsto and collecting outputs from state machine streams; and a programexecution flow controller to examine computations and data in-flight anddrive computations back and forth.
 26. The method of claim 22 whereinthe graphical user interface of the visualization graphical-basedcomponent allows a user to add one or more compute blocks, each computeblock comprising a state machine.
 27. The method of claim 22 wherein thegraphical user interface of the visualization graphical-based componentallows a user to add one or more compute blocks, each compute blockcomprising a state machine.
 28. The method of claim 22 wherein thegraphical user interface of the visualization graphical-based componentallows the user to select an input block to connect to one or more addedcompute blocks.
 29. The method of claim 22 wherein the graphical userinterface of the visualization graphical-based component allows the userto select an output from one or more added compute blocks to connect toan output block.
 30. The method of claim 22 wherein the timed eventscomprise at least one of an interval of time in which data is to becollected or discarded or a specific point in time before or after whichdata is to be collected or discarded.